01 Archivos Jar

• 1. Formato de Archivo Java™ (JAR)
  • 1. Sintaxis Archivos JAR
  • 2. Creación de un JAR
    • Opciones de la orden jar
  • 3. Visualización del contenido de un JAR
  • 4. Archivos JAR como Aplicaciones

1. Formato de Archivo Java™ (JAR)

• El formato de archivo Java™ Archive (JAR) te permite agrupar múltiples archivos en un solo archivo de archivo.
• Un archivo JAR contiene los archivos de clase y los recursos auxiliares asociados aplicaciones.

Beneficios:

Seguridad: se puede firmar digitalmente el contenido de un archivo JAR.

Tiempo de descarga reducido: cuando se trabaja con descarga de Internet pueden descargarse a un navegador en una sola transacción HTTP sin la necesidad de abrir una nueva conexión para cada archivo.

Formato comprimido: es un formato comprimido disminuyendo el espacio para su distribución y despliegue.

Empaquetado para bibliotecas Java: se pueden agregar bibliotecas, así como crear tus propias bibliotecas para distribuilas.

Sellado de paquetes: puede sellarse un paquete dentro de un archivo JAR para que todas las clases definidas en ese paquete estén dentro del archivo JAR.

Versionado de paquetes: puede contener datos sobre los archivos que contiene, como información de proveedor y versión.

Portabilidad: es una parte estándar de la API principal de la plataforma Java.

1. Sintaxis Archivos JAR

• Los archivos JAR están empaquetados con el formato de archivo ZIP.

• Para realizar tareas básicas con archivos JAR se emplea la herramienta jar del JDK, que se invoca mediante el comando jar.

Sintaxis general:

jar {ctxui}[vfm0Me] [jar-file] [manifest-file] [entry-point] [-C dir] files ...

Operaciones principales con Archivos JAR:

2. Creación de un JAR

El formato básico del comando para crear un archivo JAR es:

jar cf nombre-archivo-jar archivos(s)

Las opciones y argumentos utilizados en este comando son:

• La opción c indica se cree un archivo JAR.
• La opción f indica que la salida debe ir a un archivo en lugar de a stdout (salida por pantalla).
• nombre-archivo-jar es el nombre del archivo JAR resultante. Puede usarse cualquier nombre de archivo para un archivo JAR. Por convenio, los nombres de archivo JAR se les da una extensión .jar, aunque esto no es obligatorio.
• El argumento archivos(s) es una lista separada por espacios de uno o más archivos que deseas incluir en tu archivo JAR. El argumento archivo(s) puede contener el símbolo de comodín *. Si alguno de los “archivos de entrada” son directorios, el contenido de esos directorios se agrega al archivo JAR de forma recursiva.
• Las opciones c y f pueden aparecer en cualquier orden, pero no debe haber ningún espacio entre ellas.

Este comando generará un archivo JAR comprimido y lo colocará en el directorio actual.
El comando también generará un archivo MANIFEST.MF predeterminado para el archivo JAR.

El archivo de META-INF/MANIFEST.MF predeterminado contiene lo siguiente (depende de la versión de Java):

Manifest-Version: 1.0
Created-By: 1.8.0_181 (Oracle Corporation)

Si se le indica el nombre de la clase principal, el archivo MANIFEST.MF predeterminado se actualizará para contener la entrada Main-Class:

Main-Class: nombreClasePrincipal

Nota: Los metadatos en el archivo JAR, como los nombres de entrada, comentarios y contenido del manifiesto, deben codificarse en UTF8.

Puedes agregar cualquiera de estas opciones adicionales a las opciones cf del comando básico:

Opciones de la orden jar

Advertencia: El MANIFEST.MF debe terminar con una nueva línea o retorno de carro.
La última línea no se analizará correctamente si no termina con una nueva línea o retorno de carro.

3. Visualización del contenido de un JAR

El formato básico de la orden para ver el contenido de un archivo JAR es:

jar tf jar-file

• La opción t indica que deseas ver la tabla de contenidos del archivo JAR.
• La opción f indica que el archivo JAR cuyo contenido se va a ver.
• El argumento jar-file es la ruta y el nombre del archivo JAR cuyo contenido deseas ver.
• Las opciones t y f pueden aparecer en cualquier orden, pero no debe haber ningún espacio entre ellas.

Este comando mostrará la tabla de contenidos del archivo JAR por pantalla.

Se puede añadir la opción detallada, v, para obtener información adicional sobre tamaños de archivo y fechas de última modificación en la salida.

4. Archivos JAR como Aplicaciones

Es posible ejecutar aplicaciones empaquetadas en archivos JAR con java:

java -jar archivo-jar

• Solo se puede indicar un archivo JAR, que debe contener todo el código específico de la aplicación.

• Lo más importante es que el archivo Jar debe tener información de la clase con el main, que es el punto de entrada de la aplicación.

• Para indicar qué clase es el punto de entrada de la aplicación, debe añadirse Main-Class al manifiesto del archivo JAR.

• El encabezado tiene la forma:

Main-Class: paquete.ClasePrincipal

El valor del encabezado, paquete.ClasePrincipal, es el nombre de la clase que es el punto de entrada de la aplicación.

Nota: El atributo Main-Class es opcional en el manifiesto de un archivo JAR. Si no se especifica, el archivo JAR no se puede ejecutar directamente desde la línea de comandos.

Cuando se indica Main-Class en el archivo MANIFEST.MF, puedes ejecutar la aplicación desde la línea de órdenes:

java -jar app.jar

Para ejecutar la aplicación desde el archivo JAR que está en otro directorio, debes especificar la ruta de ese directorio:

java -jar path/app.jar

02 Creación de un JAR ejecutable con Java con Apache Maven

• 1. Introducción
• 2. Configuración manual
  • 2.1. Configuración del archivo pom.xml
  • Añadir bibliotecas con las dependencias
  • Creación de un jar ejecutable
  • 2.2. Incorporación de las dependencias dentro del JAR: maven-assembly-plugin
  • 2.3. Plugin Maven Shade: maven-shade-plugin
  • 2.4. Plugin One Jar Maven: onejar-maven-plugin
  • 2.5. Plugin Spring Boot Maven: spring-boot-maven-plugin
  • 2.6. Aplicación Web ejecutable Tomcat: tomcat7-maven-plugin

1. Introducción

Este documento explicaremos los distintos modos de empaquetar un proyecto Maven en un archivo Jar ejecutable.

Cuando creamos un archivo jar, generalmente queremos ejecutarlo fácilmente, sin utilizar el IDE. Muchas veces nos vemos sorprendidos al comprobar que el archivo de manifiesto no incorpora referencias al main o no so incluyen las bibliotecas.

Veremos varias configuraciones y pros/contras de cada uno de estos enfoques para crear un JAR ejecutable.

En este artículo, describimos muchas formas de crear un jar ejecutable con varios complementos de Maven.

2. Configuración manual

Este modo de hacerlo nos da flexiblidad, pues sólo se requiere de un proyecto maven y añadir los elementos necesarios al fichero de configuración de maven, pom.xml.

No necesitamos ninguna dependencia adicional para crear un archivo jar ejecutable. sólo necesitamos crear un proyecto Java Maven y tener al menos una clase con el método main(…), la entrada al programa.

En nuestro ejemplo, creamos una clase Java llamada AppExemplo.

También debemos asegurarnos de que nuestro pom.xml contenga estos elementos:

<modelVersion>4.0.0</modelVersion>
<groupId>com.javhoz</groupId>
<artifactId>core-java</artifactId>
<version>0.1.0-SNAPSHOT</version>
<packaging>jar</packaging>

Lo más importante aquí es el tipo de empaquetamiento, para crear un jar ejecutable el packaging tipo de jar.

Ahora podemos comenzar a usar las diversas soluciones.

2.1. Configuración del archivo pom.xml

Añadir bibliotecas con las dependencias

Comencemos con un enfoque manual con la ayuda del maven-dependency-plugin y copy-dependencies, que copia las dependencias del proyecto desde el repositorio a una ubicación definida, en este caso el directorio libs:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    <executions>
        <execution>
            <id>copy-dependencies</id>
            <phase>prepare-package</phase>
            <goals>
                <goal>copy-dependencies</goal>
            </goals>
            <configuration>
                <outputDirectory>
                    ${project.build.directory}/libs
                </outputDirectory>
            </configuration>
        </execution>
    </executions>
</plugin>

Hay dos aspectos importantes a tener en cuenta.

Primero, especificamos la meta copy-dependencies, que le dice a Maven que copie estas dependencias en el directorio de salida especificado. En nuestro caso, crearemos una carpeta llamada libs dentro del directorio de despliegue del proyecto (que suele llamarse target).

Creación de un jar ejecutable

En segundo lugar, vamos a crear un jar ejecutable indicándoles la ruta a las biblitecas anteriores en el classpath, dentro del plugin que permite crear jar :

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <configuration>
        <archive>
            <manifest>
                <addClasspath>true</addClasspath>
                <classpathPrefix>libs/</classpathPrefix>
                <mainClass>
                    com.javhoz.executable.AppExemplo
                </mainClass>
            </manifest>
        </archive>
    </configuration>
</plugin>

La parte más importante de esto es la configuración del archivo que se produce dentro del archivo MANIFEST.MF del JAR https://docs.oracle.com/javase/tutorial/deployment/jar/manifestindex.html.

Con esta configuración de Maven se añaden las rutas a las bibliotecas del proyecto dentro de la carpeta libs/ y se indica qué clase tiene el main.

Las ventajas y desventajas de este enfoque son:

• Ventajas: Proceso transparente, donde podemos especificar cada paso
• Inconvenientes: se trata de un proceso manual, en el que las dependencias están fuera del jar final, lo que significa que nuestro jar ejecutable únicamente se ejecutará si la carpeta libs es accesible y visible para un jar.

2.2. Incorporación de las dependencias dentro del JAR: maven-assembly-plugin

El Plugin de ensamblado de Apache Maven maven-assembly-plugin permite agregar al paquete de salida del proyecto (jar en este caso), módulos, documentación del sitio y otros archivos en un único paquete ejecutable ("…permite a los desarrolladores combinar los resultados del proyecto en un único archivo distribuible que también contiene dependencias, módulos, documentación del sitio y otros archivos").

El objetivo principal (y ahora único) en el plugin de ensamblaje es el crear un archivo único, que se utiliza para crear todos los ensamblajes.

Puedes consultar el uso de este plugin en la página oficial de Apeche Maven

La configuración del pom.xml debe ser algi similar a lo siguiente:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-assembly-plugin</artifactId>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>single</goal>
            </goals>
            <configuration>
                <archive>
                <manifest>
                    <mainClass>
                        com.javhoz.executable.AppExemplo
                    </mainClass>
                </manifest>
                </archive>
                <descriptorRefs>
                    <descriptorRef>jar-with-dependencies</descriptorRef>
                </descriptorRefs>
            </configuration>
        </execution>
    </executions>
</plugin>

En la parte descriptorRefs del código de configuración, se indica el nombre que se agregará al nombre del proyecto (puede cambiarse)

La salida en nuestro ejemplo se llamará core-java-jar-with-dependencies.jar: “Nota: … Tenga en cuenta que el complemento de ensamblaje le permite especificar varios descriptorRefsa la vez para producir múltiples tipos de ensamblajes en una sola invocación.”

• Ventajas: las dependencias se añaden dentro de un único archivo jar, dándole portabilidad “total”.
• Desventajas: no podemos reubicar las calses del proyecto. A veces, el tamaño puede aumentar considerablemente y sólo precisamos distribuir nuestras clases.

2.3. Plugin Maven Shade: maven-shade-plugin

El plugin de sombreado de Apache Maven proporciona la capacidad de empaquetar el artefacto en un uber-jar, “..proporciona la capacidad de empaquetar el artefacto en un uber-jar, incluidas sus dependencias y sombrear (es decir, cambiar el nombre) los paquetes de algunas de las dependencias.”

Esto es, una vez creado el JAR permite cambiar las dependencias si se precisa en algún momento (versiones, etc.). Uso del plugin: https://maven.apache.org/plugins/maven-shade-plugin/usage.html

Configuración del pom.xml:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <executions>
        <execution>
            <goals>
                <goal>shade</goal>
            </goals>
            <configuration>
                <shadedArtifactAttached>true</shadedArtifactAttached>
                <transformers>
                    <transformer implementation=
                      "org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                        <mainClass>com.javhoz.executable.AppExemplo</mainClass>
                </transformer>
            </transformers>
        </configuration>
        </execution>
    </executions>
</plugin>

El archivo de configuración tiene 3 partes principales:

• Necesitamos especificar la clase principal de la aplicación: com.javhoz.executable.AppExemplo
• <shadedArtifactAttached> indicas las dependencias que deben ser empaquetadas en el jar.
• Debe indicarse la implementación del transformador, transformer implementation=, que en el ejemplo se emplea el estándar que añade las entradas al archiv MANIFEST.

El archivo de salida se llamará core-java-0.1.0-SNAPSHOT-shaded.jar, donde core-java es el nombre de nuestro proyecto seguido por la versión de snapshot y el nombre del plugin.

• Ventajas: dependencias dentro del archivo jar, control avanzado del empaquetado del proyecto, con sombreado y reubicación de clases.
• Deventajas: configuración compleja (especialmente si queremos usar funciones avanzadas).

2.4. Plugin One Jar Maven: onejar-maven-plugin

Otra opción, poco recomendable (como curiosidad), menos interesante y comercial para crear un jar ejecutable es el proyecto One Jar, que proporciona un loader de clases personalizado que sabe cómo cargar clases y recursos desde archivos jar dentro de un archivo, en lugar de desde archivos jar en el sistema de archivos. Requiere dependencias.

Configuración del pom.xml:

<plugin>
    <groupId>com.jolira</groupId>
    <artifactId>onejar-maven-plugin</artifactId>
    <executions>
        <execution>
            <configuration>
                <mainClass>com.javhoz.executable.AppExemplo</mainClass>
                <attachToBuild>true</attachToBuild>
                <filename>
                  ${project.build.finalName}.${project.packaging}
                </filename>
            </configuration>
            <goals>
                <goal>one-jar</goal>
            </goals>
        </execution>
    </executions>
</plugin>

• Se debe especificar la clase principal y adjuntar todas las dependencias a la construcción, utilizando attachToBuild = true.
• Se debe proporcionar el nombre de archivo de salida.
• El objetivo para Maven es one-jar.

One Jar es una solución comercial que hará que las dependencias no se expandan en el sistema de archivos en tiempo de ejecución.

• Ventajas: modelo de delegación limpio, permite que las clases estén en el nivel superior de One Jar, admite archivos jar externos y puede admitir bibliotecas nativas
• Desventajas:: no es compatible desde 2012

2.5. Plugin Spring Boot Maven: spring-boot-maven-plugin

Otr opción interesante es el Plugin Spring Boot Maven, que permite empaquetar archivos jar o war ejecutables y ejecutar una aplicación “in situ”.

Para usarlo, necesitamos usar al menos la versión 3.2 de Maven. La descripción detallada está disponible esta disponible en la página de Spring.

Configuración del pom.xml:

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <executions>
        <execution>
            <goals>
                <goal>repackage</goal>
            </goals>
            <configuration>
                <classifier>spring-boot</classifier>
                <mainClass>
                  com.javhoz.executable.AppExemplo
                </mainClass>
            </configuration>
        </execution>
    </executions>
</plugin>

Hay dos diferencias entre el plugin Spring y los demás:

El objetivo (goal) de la ejecución se llama repackage, y el clasificador (classifier) se llama spring-boot.

NO NECESITAMOS tener una aplicación Spring Boot para usar este plugin.

• Ventajas: dependencias dentro de un archivo jar, podemos ejecutarlo en cualquier ubicación accesible, control avanzado del empaquetado del proyecto, excluyendo dependencias del archivo jar, etc., empaquetado de otros tipos de archivo como war
• Desventajas: añade clases innecesarias de Spring y Spring Boot, pues no requiere usar Spring Boot para emplear este plugin.

2.6. Aplicación Web ejecutable Tomcat: tomcat7-maven-plugin

Por último, si queremos hacer una aplicación web independiente que esté empaquetada dentro de un archivo jar.

Necesitamos usar un plugin diferente, diseñado para crear archivos jar ejecutables:

Configuración del pom.xml:

<plugin>
    <groupId>org.apache.tomcat.maven</groupId>
    <artifactId>tomcat7-maven-plugin</artifactId>
    <version>2.0</version>
    <executions>
        <execution>
            <id>tomcat-run</id>
            <goals>
                <goal>exec-war-only</goal>
            </goals>
            <phase>package</phase>
            <configuration>
                <path>/</path>
                <enableNaming>false</enableNaming>
                <finalName>webapp.jar</finalName>
                <charset>utf-8</charset>
            </configuration>
        </execution>
    </executions>
</plugin>

El goal está configurado como exec-war-only, la ruta al servidor se especifica dentro de la etiqueta de configuration, con propiedades adicionales, como finalName, charset, etc.

Para construir un jar, ejecutamos mvn package, lo que dará como resultado la creación de webapp.jar en el directorio target.

Para ejecutar la aplicación, simplemente escribimos java -jar target/webapp.jar en la consola y tratamos de probarlo especificando el localhost:8080/ en un navegador. Ya tenemos nuestra aplicación Web ejecutándose desde línea de órdenes un archivo JAR ;-)

• Ventajas: tener un único archivo, fácil de implementar y ejecutar
• Desventajas: el tamaño del archivo es mucho mayor, debido al empaquetado de la distribución integrada de Tomcat dentro de un archivo jar.

<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>javax.servlet-api</artifactId>
    <scope>provided</scope>
</dependency>

03. Dependencias Maven.

• 1. Dependencias Maven.
  • 2. Logging
  • 2. Json
    • 2.1 Gson
    • 2.2. Jackson Databind
    • 2.3. Jackson Core
  • 3. JUnit
  • 4. Drivers JDBC
    • 4.1. H2
    • 4.2. SQLite JDBC Driver
    • 4.3. PostgreSQL JDBC Driver
    • 4.4. MySQL Connector/J
    • 4.5. HyperSQL Database (HSQLDB)
  • 5. Dependencias para JPA
    • 5.1. Jakarta Persistence API (JPA)
    • 5.2. Hibernate
    • 5.3. EclipseLink
  • 6. Dependencias para Spring
    • 6.1. Spring Core
    • 6.2. Spring Boot
    • 6.3. Spring Data JPA
    • 6.4. Spring Boot Starter Data JPA
  • 7. Lenguajes sobre JVM
    • 7.1. Kotlin
    • 7.2. Scala
• Referencias

1. Dependencias Maven.

2. Logging

SLF4J (The Simple Logging Facade for Java) es una fachada o interfaz para varios sistemas de registro de eventos (logging) en Java. Permite a los desarrolladores cambiar de sistema de registro de eventos en tiempo de ejecución sin tener que modificar el código fuente. Para más información, visita la página oficial de SLF4J: http://www.slf4j.org/

https://mvnrepository.com/artifact/org.slf4j/slf4j-api https://central.sonatype.com/artifact/org.slf4j/slf4j-api

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>2.0.16</version>
</dependency>

Además, precisamos alguna implementación de SLF4J. En este caso vamos a usar Logback:

https://mvnrepository.com/artifact/ch.qos.logback/logback-classic https://central.sonatype.com/artifact/ch.qos.logback/logback-classic

<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-classic</artifactId>
    <version>1.5.16</version>
</dependency>

2. Json

2.1 Gson

Gson es una biblioteca Java que se utiliza para convertir objetos Java en su representación JSON. También puede ser utilizado para convertir una cadena JSON en un objeto Java equivalente. Gson es una biblioteca de código abierto desarrollada por Google. Puedes encontrar más información en la página oficial de Gson: https://github.com/google/gson

https://mvnrepository.com/artifact/com.google.code.gson/gson https://central.sonatype.com/artifact/com.google.code.gson/gson

<dependency>
    <groupId>com.google.code.gson</groupId>
    <artifactId>gson</artifactId>
    <version>2.11.0</version>
</dependency>

2.2. Jackson Databind

Jackson es una biblioteca Java de código abierto para convertir objetos Java en su representación JSON y viceversa. Jackson es una de las bibliotecas de serialización y deserialización JSON más populares en Java. Puedes encontrar más información en la página oficial de Jackson: https://github.com/FasterXML/jackson

https://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-databind https://central.sonatype.com/artifact/com.fasterxml.jackson.core/jackson-databind

<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>2.18.2</version>
</dependency>

2.3. Jackson Core

Jackson Core es una biblioteca Java de código abierto para procesar JSON (Stream API). Jackson Core proporciona las clases básicas para trabajar con JSON, como JsonNode, JsonParser y JsonGenerator. Puedes encontrar más información en la página oficial de Jackson: https://github.com/FasterXML/jackson-core

https://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-core https://central.sonatype.com/artifact/com.fasterxml.jackson.core/jackson-core

<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-core</artifactId>
    <version>2.18.2</version>
</dependency>

3. JUnit

JUnit es un framework open-source que se utiliza para realizar pruebas unitarias en Java. JUnit es una herramienta importante en el desarrollo de software, ya que permite a los desarrolladores probar su código de manera eficiente y asegurarse de que funciona correctamente. Puedes encontrar más información en la página oficial de JUnit: https://junit.org/junit5/

https://mvnrepository.com/artifact/org.junit.jupiter/junit-jupiter-api https://central.sonatype.com/artifact/org.junit.jupiter/junit-jupiter-api

<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter-api</artifactId>
    <version>5.11.4</version>
    <scope>test</scope>
</dependency>

Ejemplo de uso:

import static org.junit.jupiter.api.Assertions.assertEquals;
import org.junit.jupiter.api.Test;

public class MyTest {

    @Test
    public void test() {
        assertEquals(2, 1 + 1);
    }
}

4. Drivers JDBC

Para trabajar con bases de datos, necesitamos los drivers JDBC correspondientes.

4.1. H2

H2 es una base de datos relacional escrita en Java. Es muy rápida, de código abierto y se puede ejecutar en modo embebido o en modo servidor. Además, admite transacciones, encriptación, funciones de usuario o procedimientos almacenados. Además, puede almacenarse en memoria o en disco.

Puedes encontrar más información en la página oficial de H2: http://www.h2database.com/

https://mvnrepository.com/artifact/com.h2database/h2 https://central.sonatype.com/artifact/com.h2database/h2

<dependency>
    <groupId>com.h2database</groupId>
    <artifactId>h2</artifactId>
    <version>2.3.232</version>
</dependency>

Es importante hacer notar que las incompatibilidades entre versiones diferentes de H2, por lo que se recomienda tener control sobre qué versión se está utilizando.

URL: jdbc:h2:mem:testdb (base de datos en memoria) Driver: org.h2.Driver URL (fichero): jdbc:h2:rutaALaBaseDatos;DATABASE_TO_UPPER=false (base de datos en fichero)

El Driver JDBC para H2 hace la conversión automática de los nombres de las tablas y columnas a mayúsculas, por lo que si queremos conservar los nombres originales, debemos añadir DATABASE_TO_UPPER=false a la URL de conexión.

4.2. SQLite JDBC Driver

SQLite es una base de datos relacional embebida, que no requiere un servidor. Es muy ligera y rápida, y se puede utilizar en aplicaciones de escritorio, móviles o en la web. Puedes encontrar más información en la página oficial de SQLite: https://www.sqlite.org/index.html

Existen varias implementaciones de SQLite en Java, pero vamos a usar Xerial SQLite JDBC Driver:

https://mvnrepository.com/artifact/org.xerial/sqlite-jdbc https://central.sonatype.com/artifact/org.xerial/sqlite-jdbc

<dependency>
    <groupId>org.xerial</groupId>
    <artifactId>sqlite-jdbc</artifactId>
    <version>3.48.0.0</version>
</dependency>

URL: jdbc:sqlite:rutaALaBaseDatos (base de datos en fichero) Driver: org.sqlite.JDBC

Existen otras API para SQLite, como las versiones originales de androidx: https://developer.android.com/jetpack/androidx/releases/sqlite, pero dicha versión no es compatible con Java SE y se usaba antiguamente para android, antes de la aparicion de Room.

4.3. PostgreSQL JDBC Driver

PostgreSQL es un sistema de gestión de bases de datos relacional de código abierto y muy potente. Puedes encontrar más información en la página oficial de PostgreSQL: https://www.postgresql.org/

https://mvnrepository.com/artifact/org.postgresql/postgresql https://central.sonatype.com/artifact/org.postgresql/postgresql

<dependency>
    <groupId>org.postgresql</groupId>
    <artifactId>postgresql</artifactId>
    <version>42.7.5</version>
</dependency>

URL: jdbc:postgresql://localhost:5432/nombredelabasededatos Driver: org.postgresql.Driver

El usuario y la contraseña se pasarán como parámetros en la URL de conexión:

    String url = "jdbc:postgresql://localhost:5432/nombredelabasededatos";
    String user = "usuario";
    String password = "contraseña";
    Connection conn = DriverManager.getConnection(url, user, password);

Si queremos añadirlos a la URL:

    String url = "jdbc:postgresql://localhost:5432/nombredelabasededatos?user=usuario&password=contraseña";
    Connection conn = DriverManager.getConnection(url);

4.4. MySQL Connector/J

MySQL Connector/J es un controlador JDBC Tipo 4, lo que significa que es una implementación Java pura del protocolo MySQL y no depende de las bibliotecas de cliente MySQL. Como los anteriores, este controlador admite el registro automático con DriverMaganer, lo que significa que no es necesario cargar explícitamente el controlador.

https://mvnrepository.com/artifact/com.mysql/mysql-connector-j https://central.sonatype.com/artifact/com.mysql/mysql-connector-j

<dependency>
    <groupId>com.mysql</groupId>
    <artifactId>mysql-connector-j</artifactId>
    <version>9.1.0</version>
</dependency>

URL: jdbc:mysql://localhost:3306/nombredelabasededatos Driver: com.mysql.cj.jdbc.Driver

La URL puede recoger parámetros, como:

    String url = "jdbc:mysql://localhost:3306/nombredelabasededatos?user=usuario&password=contraseña";
    Connection conn = DriverManager.getConnection(url);

4.5. HyperSQL Database (HSQLDB)

HSQLDB es una base de datos relacional escrita en Java. Es muy rápida, de código abierto y se puede ejecutar en modo embebido o en modo servidor: https://hsqldb.org/

https://mvnrepository.com/artifact/org.hsqldb/hsqldb https://central.sonatype.com/artifact/org.hsqldb/hsqldb

<dependency>
    <groupId>org.hsqldb</groupId>
    <artifactId>hsqldb</artifactId>
    <version>2.7.4</version>
</dependency>

URL: jdbc:hsqldb:mem:testdb (base de datos en memoria) Driver: org.hsqldb.jdbc.JDBCDriver URL para servidor: jdbc:hsqldb:hsql://localhost/testdb URL para fichero: jdbc:hsqldb:file:nombrebasededatos

5. Dependencias para JPA

5.1. Jakarta Persistence API (JPA)

La Java Persistence API (JPA) es una especificación de Java que describe la gestión de la persistencia de los objetos en las aplicaciones Java. JPA define un conjunto de interfaces y anotaciones que permiten a los desarrolladores mapear objetos Java a tablas de bases de datos y viceversa. Puedes encontrar más información en la página oficial de JPA:

• https://jakarta.ee/specifications/persistence/
• https://github.com/jakartaee/persistence
• Javadoc: https://jakartaee.github.io/persistence/latest/api/jakarta.persistence/module-summary.html

https://mvnrepository.com/artifact/jakarta.persistence/jakarta.persistence-api https://central.sonatype.com/artifact/jakarta.persistence/jakarta.persistence-api

JPA 3.1:

<dependency>
    <groupId>jakarta.persistence</groupId>
    <artifactId>jakarta.persistence-api</artifactId>
    <version>3.1.0</version>
</dependency>

JPA 3.2:

<dependency>
    <groupId>jakarta.persistence</groupId>
    <artifactId>jakarta.persistence-api</artifactId>
    <version>3.2.0</version>
</dependency>

5.2. Hibernate

Hibernate es un framework de mapeo objeto-relacional (ORM) para Java. Hibernate simplifica el desarrollo de aplicaciones Java que interactúan con bases de datos relacionales. Puedes encontrar más información en la página oficial de Hibernate: https://hibernate.org/

https://mvnrepository.com/artifact/org.hibernate/hibernate-core https://central.sonatype.com/artifact/org.hibernate/hibernate-core

La versión compatible con JPA 3.1 es la versión 6:

<dependency>
    <groupId>org.hibernate.orm</groupId>
    <artifactId>hibernate-core</artifactId>
    <version>6.6.5.Final</version>
</dependency>

La versión compatible con JPA 3.2 es la versión 7, que todavía está en desarrollo:

<dependency>
    <groupId>org.hibernate.orm</groupId>
    <artifactId>hibernate-core</artifactId>
    <version>7.0.0.Beta3</version>
</dependency>

Pronto se lanzará la versión final de Hibernate 7, que será compatible con JPA 3.2. Esperamos.

5.3. EclipseLink

EclipseLink es otro framework de mapeo objeto-relacional (ORM) para Java. EclipseLink es una implementación de la especificación JPA y proporciona una serie de características avanzadas, como el mapeo de herencia, el mapeo de tablas, el mapeo de relaciones y la consulta de objetos. Puedes encontrar más información en la página oficial de EclipseLink: https://www.eclipse.org/eclipselink/

https://mvnrepository.com/artifact/org.eclipse.persistence/eclipselink https://central.sonatype.com/artifact/org.eclipse.persistence/eclipselink

La versión compatible con JPA 3.1 es la versión 4:

<dependency>
    <groupId>org.eclipse.persistence</groupId>
    <artifactId>eclipselink</artifactId>
    <version>4.0.5</version>
</dependency>

La versión compatible con JPA 3.2 es la versión 5, que todavía está en desarrollo:

<dependency>
    <groupId>org.eclipse.persistence</groupId>
    <artifactId>eclipselink</artifactId>
    <version>5.0.0-B05</version>
</dependency>

Pronto se lanzará la versión final de EclipseLink 5, que será compatible con JPA 3.2. Esperamos.

6. Dependencias para Spring

6.1. Spring Core

Spring Core es el núcleo del framework Spring. Proporciona las funcionalidades básicas de Spring, como la inyección de dependencias y la gestión de transacciones. Puedes encontrar más información en la página oficial de Spring: https://spring.io/projects/spring-framework

https://mvnrepository.com/artifact/org.springframework/spring-core https://central.sonatype.com/artifact/org.springframework/spring-core

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <version>6.2.2</version>
</dependency>

6.2. Spring Boot

Spring Boot es un proyecto de Spring que simplifica el desarrollo de aplicaciones Java. Proporciona una serie de características, como la configuración automática, el embebido de servidores, la gestión de dependencias y la creación de aplicaciones ejecutables. Puedes encontrar más información en la página oficial de Spring Boot: https://spring.io/projects/spring-boot

https://mvnrepository.com/artifact/org.springframework.boot/spring-boot https://central.sonatype.com/artifact/org.springframework.boot/spring-boot

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot</artifactId>
    <version>3.4.1</version>
</dependency>

Spring Boot Starter es una colección de dependencias que se utilizan comúnmente en las aplicaciones Spring Boot. Puedes encontrar más información en la página oficial de Spring Boot: https://spring.io/projects/spring-boot

https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter https://central.sonatype.com/artifact/org.springframework.boot/spring-boot-starter

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter</artifactId>
    <version>3.4.1</version>
</dependency>

6.3. Spring Data JPA

Spring Data JPA es un proyecto de Spring que simplifica el acceso a datos en aplicaciones Java. Proporciona una serie de características, como la creación de repositorios, la generación de consultas y la gestión de transacciones. Puedes encontrar más información en la página oficial de Spring Data JPA: https://spring.io/projects/spring-data-jpa

https://mvnrepository.com/artifact/org.springframework.data/spring-data-jpa https://central.sonatype.com/artifact/org.springframework.data/spring-data-jpa

<dependency>
    <groupId>org.springframework.data</groupId>
    <artifactId>spring-data-jpa</artifactId>
    <version>3.4.2</version>
</dependency>

6.4. Spring Boot Starter Data JPA

Spring Boot Starter Data JPA es una colección de dependencias que se utilizan comúnmente en las aplicaciones Spring Boot que utilizan Spring Data JPA. Puedes encontrar más información en la página oficial de Spring Boot: https://spring.io/projects/spring-boot

https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-data-jpa https://central.sonatype.com/artifact/org.springframework.boot/spring-boot-starter-data-jpa

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-jpa</artifactId>
    <version>3.4.1</version>
</dependency>

7. Lenguajes sobre JVM

7.1. Kotlin

Kotlin es un lenguaje de programación moderno y conciso que se ejecuta sobre la JVM. Kotlin es interoperable con Java, lo que significa que puedes utilizar las bibliotecas de Java en Kotlin y viceversa. Puedes encontrar más información en la página oficial de Kotlin: https://kotlinlang.org/

IDEs como IntelliJ IDEA o Android Studio soportan Kotlin de forma nativa, pero también puedes usar Kotlin en otros IDE añadiendo las dependencias necesarias.

https://mvnrepository.com/artifact/org.jetbrains.kotlin/kotlin-stdlib https://central.sonatype.com/artifact/org.jetbrains.kotlin/kotlin-stdlib

<dependency>
    <groupId>org.jetbrains.kotlin</groupId>
    <artifactId>kotlin-stdlib</artifactId>
    <version>2.1.0</version>
</dependency>

7.2. Scala

Scala es un lenguaje de programación funcional y orientado a objetos que se ejecuta sobre la JVM. Scala es interoperable con Java, lo que significa que puedes utilizar las bibliotecas de Java en Scala y viceversa. Puedes encontrar más información en la página oficial de Scala: https://www.scala-lang.org/

IDEs como IntelliJ IDEA o Eclipse soportan Scala de forma nativa, pero también puedes usar Scala en otros IDE añadiendo las dependencias necesarias.

https://mvnrepository.com/artifact/org.scala-lang/scala3-library_3 https://central.sonatype.com/artifact/org.scala-lang/scala3-library_3

<dependency>
    <groupId>org.scala-lang</groupId>
    <artifactId>scala3-library_3</artifactId>
    <version>3.6.3</version>
</dependency>

Referencias

• Maven Repository

• Central Sonatype Repository

• SLF4J

• Gson

• Spring

00.01 Java Stream API

• Introducción
• 1. Definición de Java Stream
• 2. Procesamiento de Streams
• 3. Crear un Stream
• 4. Operaciones Terminales y No Terminales
• 5. Operaciones No Terminales
  • filter()
  • map()
  • flatMap()
  • distinct()
  • limit()
  • peek()
• 6. Operaciones Terminales
  • anyMatch()
  • allMatch()
  • noneMatch()
  • findFirst()
  • findAny()
  • forEach()
  • collect()
  • count()
  • reduce()
  • min() y max()
  • forEachOrdered()
• Resumen

Introducción

La API de Streams de Java ofrece un enfoque funcional para el procesamiento de colecciones de objetos. Se introdujo en Java 8 junto con varias otras características de programación funcional. Este tutorial de Java Stream explicará cómo funcionan estos streams funcionales y cómo usarlos.

La API de Java Stream no está relacionada con Java InputStream y Java OutputStream de Java IO. InputStream y OutputStream se relacionan con flujos de bytes, mientras que la API de Stream de Java se utiliza para procesar flujos de objetos.

1. Definición de Java Stream

Un Stream en Java es un componente capaz de realizar una iteración interna de sus elementos, lo que significa que puede iterar sobre sus elementos por sí mismo. En contraste, al usar las características de iteración de Java Collections (por ejemplo, un Java Iterator o el bucle for-each de Java utilizado con un Java Iterable), debes implementar la iteración de los elementos tú mismo.

2. Procesamiento de Streams

Puedes adjuntar oyentes a un Stream. Estos oyentes se llaman cuando el Stream itera internamente los elementos. Los oyentes se llaman una vez por cada elemento en el stream. De esta manera, cada oyente procesa cada elemento en el stream. Esto se denomina procesamiento de stream.

Los oyentes de un stream forman una cadena. El primer oyente en la cadena puede procesar el elemento en el stream y luego devolver un nuevo elemento para que el siguiente oyente en la cadena lo procese. Un oyente puede devolver el mismo elemento o uno nuevo, dependiendo del propósito de ese oyente (procesador).

3. Crear un Stream

Hay muchas formas de obtener un Stream en Java. Una de las formas más comunes de obtener un Stream es desde una Java Collection. Un ejemplo de cómo obtener un Stream desde una Java List:

List<String> items = new ArrayList<String>();

items.add("uno");
items.add("dos");
items.add("tres");

Stream<String> stream = items.stream();    

Este ejemplo crea primero una lista de Java, luego agrega tres Java Strings y, finalmente, llama al método stream() para obtener una instancia de Stream.

4. Operaciones Terminales y No Terminales

La interfaz Stream tiene una selección de operaciones terminales y no terminales. Una operación no terminal de stream es una operación que agrega un oyente al stream sin hacer nada más. Una operación terminal de stream es una operación que inicia la iteración interna de los elementos, llama a todos los oyentes y devuelve un resultado.

Un ejemplo de Java Stream que contiene tanto una operación no terminal como una terminal:

import java.util.ArrayList;
import java.util.List;
import java.util.stream.Stream;

public class EjemplosDeStream {

    public static void main(String[] args) {
        List<String> listaDeCadenas = new
                ArrayList<>();

        listaDeCadenas.add("Uno");
        listaDeCadenas.add("Dos");
        listaDeCadenas.add("Tres");

        // Operación no terminal (filter)
        Stream<String> streamFiltrado = listaDeCadenas.stream().filter(s -> s.startsWith("T"));

        // Operación terminal (forEach)
        streamFiltrado.forEach(System.out::println);
    }
}

En este ejemplo, filter es una operación no terminal que filtra elementos basándose en el predicado proporcionado. Luego, forEach es una operación terminal que itera sobre los elementos restantes y aplica la función de impresión.

5. Operaciones No Terminales

Las operaciones no terminales de stream devuelven un nuevo Stream. Estas operaciones no realizan ninguna iteración interna. Se ejecutan “perezosamente”, lo que significa que no realizan ninguna acción hasta que se activa una operación terminal.

filter()

La operación filter es una operación no terminal que acepta un Java Predicate)como argumento y devuelve un nuevo Stream que contiene solo los elementos que cumplen con el predicado.

List<String> listaDeCadenas = Arrays.asList("Uno", "Dos", "Tres", "Cuatro", "Cinco");

// Filtrar elementos que comienzan con "C"
Stream<String> streamFiltrado = listaDeCadenas.stream().filter(s -> s.startsWith("C"));

// Imprimir elementos
streamFiltrado.forEach(System.out::println);

En este ejemplo, filter se utiliza para seleccionar solo las cadenas que comienzan con “C”.

map()

La operación map es una operación no termina que transforma cada elemento del Stream utilizando la función proporcionada como argumento. Devuelve un nuevo Stream que contiene los elementos transformados:

<R> Stream<R> map(Function<? super T,? extends R> mapper)
R apply(T t) // "método" de la interface Function

List<String> listaDeCadenas = Arrays.asList("apple", "banana", "orange");

// Convertir a mayúsculas
Stream<String> streamMayusculas = listaDeCadenas.stream().map(String::toUpperCase);

// Imprimir elementos
streamMayusculas.forEach(System.out::println);

En este ejemplo, map se utiliza para convertir cada cadena a mayúsculas.

flatMap()

La operación flatMap es una operación no terminal que transforma cada elemento del Stream en cero o más elementos según la función proporcionada como argumento. Luego, combina los elementos resultantes en un solo Stream.

<R> Stream<R> flatMap(Function<? super T,? extends Stream<? extends R>> mapper)
R apply(T t)

List<List<Integer>> numeros = Arrays.asList(
        Arrays.asList(1, 2, 3),
        Arrays.asList(4, 5, 6),
        Arrays.asList(7, 8, 9)
);

// Obtener un solo Stream de todos los números
Stream<Integer> numerosStream = numeros.stream().flatMap(List::stream);

// Imprimir elementos
numerosStream.forEach(System.out::println);

En este ejemplo, flatMap se utiliza para obtener un solo Stream de todos los números en las listas anidadas.

distinct()

La operación distinct es una operación no terminal que elimina los elementos duplicados del Stream, basándose en su implementación del método equals().

List<String> listaDeCadenas = Arrays.asList("apple", "banana", "orange", "banana", "apple");

// Eliminar duplicados
Stream<String> streamSinDuplicados = listaDeCadenas.stream().distinct();

// Imprimir elementos
streamSinDuplicados.forEach(System.out::println);

En este ejemplo, distinct se utiliza para eliminar las cadenas duplicadas.

limit()

La operación limit es una operación no terminal que reduce la longitud del Stream a la cantidad especificada.

List<String> listaDeCadenas = Arrays.asList("apple", "banana", "orange", "grape");

// Limitar a los primeros dos elementos
Stream<String> streamLimitado = listaDeCadenas.stream().limit(2);

// Imprimir elementos
streamLimitado.forEach(System.out::println);

En este ejemplo, limit se utiliza para limitar el Stream a los primeros dos elementos.

peek()

La operación peek es una operación no terminal que permite realizar un side effect en cada elemento del Stream, como imprimir el elemento antes de que se pase a la siguiente operación.

List<String> listaDeCadenas = Arrays.asList("apple", "banana", "orange");

// Imprimir cada elemento antes de la transformación
List<String> resultado = listaDeCadenas.stream()
        .peek(System.out::println)
        .map(String::toUpperCase)
        .collect(Collectors.toList());

En este ejemplo, peek se utiliza para imprimir cada elemento antes de que se transforme a mayúsculas.

6. Operaciones Terminales

Las operaciones terminales de stream inician la iteración interna de los elementos y devuelven un resultado final. Después de que se realiza una operación terminal, un Stream no puede ser utilizado de nuevo.

anyMatch()

La operación anyMatch es una operación terminal que devuelve true si al menos un elemento del Stream cumple con la condición dada, de lo contrario, devuelve false.

List<String> listaDeCadenas = Arrays.asList("apple", "banana", "orange");

// Verificar si alguna cadena contiene "nan"
boolean contieneNan = listaDeCadenas.stream().anyMatch(s -> s.contains("nan"));

System.out.println(contieneNan);  // Salida: true

En este ejemplo, anyMatch se utiliza para verificar si alguna cadena contiene la subcadena “nan”.

allMatch()

La operación allMatch es una operación terminal que devuelve true si todos los elementos del Stream cumplen con la condición dada, de lo contrario, devuelve false.

List<String> listaDeCadenas = Arrays.asList("apple", "banana", "orange");

// Verificar si todas las cadenas tienen longitud mayor que 3
boolean todasLargas = listaDeCadenas.stream().allMatch(s -> s.length() > 3);

System.out.println(todasLargas);  // Salida: true

En este ejemplo, allMatch se utiliza para verificar si todas las cadenas tienen una longitud mayor que 3.

noneMatch()

La operación noneMatch es una operación terminal que devuelve true si ninguno de los elementos del Stream cumple con la condición dada, de lo contrario, devuelve false.

List<String> listaDeCadenas = Arrays.asList("apple", "banana", "orange");

// Verificar si ninguna cadena contiene "grape"
boolean ningunaContieneUva = listaDeCadenas.stream().noneMatch(s -> s.contains("gr

ape"));

System.out.println(ningunaContieneUva);  // Salida: true

En este ejemplo, noneMatch se utiliza para verificar si ninguna cadena contiene la subcadena “grape”.

findFirst()

La operación findFirst es una operación terminal que devuelve el primer elemento del Stream en un Optional. Si el Stream está vacío, devuelve un Optional vacío.

List<String> listaDeCadenas = Arrays.asList("apple", "banana", "orange");

// Obtener el primer elemento
Optional<String> primerElemento = listaDeCadenas.stream().findFirst();

primerElemento.ifPresent(System.out::println);  // Imprimir el primer elemento si está presente

En este ejemplo, findFirst se utiliza para obtener el primer elemento de la lista.

findAny()

La operación findAny es una operación terminal que devuelve cualquier elemento del Stream en un Optional. Si el Stream está vacío, devuelve un Optional vacío.

List<String> listaDeCadenas = Arrays.asList("apple", "banana", "orange");

// Obtener cualquier elemento
Optional<String> cualquierElemento = listaDeCadenas.stream().findAny();

cualquierElemento.ifPresent(System.out::println);  // Imprimir cualquier elemento si está presente

En este ejemplo, findAny se utiliza para obtener cualquier elemento de la lista.

forEach()

La operación forEach es una operación terminal que ejecuta una acción para cada elemento del Stream.

List<String> listaDeCadenas = Arrays.asList("apple", "banana", "orange");

// Imprimir cada elemento
listaDeCadenas.stream().forEach(System.out::println);

En este ejemplo, forEach se utiliza para imprimir cada elemento de la lista.

collect()

La operación collect es una operación terminal que transforma los elementos del Stream en una estructura de datos diferente, como una List, Set, o Map. Se utiliza junto con la interfaz Collector.

List<String> listaDeCadenas = Arrays.asList("apple", "banana", "orange");

// Recoger elementos en una List
List<String> listaRecolectada = listaDeCadenas.stream().collect(Collectors.toList());

// Imprimir elementos
listaRecolectada.forEach(System.out::println);

En este ejemplo, collect se utiliza para recolectar los elementos en una List.

count()

La operación count es una operación terminal que devuelve el número de elementos en el Stream.

List<String> listaDeCadenas = Arrays.asList("apple", "banana", "orange");

// Contar elementos
long cantidad = listaDeCadenas.stream().count();

System.out.println(cantidad);  // Salida: 3

En este ejemplo, count se utiliza para contar el número de elementos en la lista.

reduce()

La operación reduce es una operación terminal que combina los elementos del Stream en un solo resultado mediante una función asociativa y un valor identidad. Puede devolver un Optional si el Stream está vacío.

List<Integer> numeros = Arrays.asList(1, 2, 3, 4, 5);

// Sumar todos los elementos
Optional<Integer> suma = numeros.stream().reduce(Integer::sum);

suma.ifPresent(System.out::println);  // Imprimir la suma si está presente

En este ejemplo, reduce se utiliza para sumar todos los elementos de la lista.

min() y max()

Las operaciones min y max son operaciones terminales que devuelven el elemento mínimo y máximo del Stream, respectivamente, basándose en el orden natural o un comparador proporcionado.

List<Integer> numeros = Arrays.asList(3, 1, 4, 1, 5, 9, 2, 6, 5);

// Encontrar el mínimo y el máximo
Optional<Integer> minimo = numeros.stream().min(Comparator.naturalOrder());
Optional<Integer> maximo = numeros.stream().max(Comparator.naturalOrder());

minimo.ifPresent(System.out::println);  // Imprimir el mínimo si está presente
maximo.ifPresent(System.out::println);  // Imprimir el máximo si está presente

En este ejemplo, min y max se utilizan para encontrar el elemento mínimo y máximo de la lista.

forEachOrdered()

La operación forEachOrdered es similar a forEach, pero garantiza que los elementos se procesen en orden en un Stream paralelo.

List<String> listaDeCadenas = Arrays.asList("apple", "banana", "orange");

// Imprimir cada elemento en orden en un Stream paralelo
listaDeCadenas.parallelStream().forEachOrdered(System.out::println);

En este ejemplo, forEachOrdered se utiliza para imprimir cada elemento en orden en un Stream paralelo.

Resumen

En Java, los Streams proporcionan una forma declarativa y funcional de procesar colecciones de datos. Las operaciones de stream se dividen en dos categorías: operaciones no terminales y operaciones terminales. Las operaciones no terminales se componen para formar una cadena de operaciones que se ejecutan perezosamente. La ejecución se inicia solo cuando se encuentra una operación terminal.

Las operaciones no terminales, como filter, map, flatMap, distinct, limit, y peek, permiten filtrar, transformar y manipular los elementos del Stream. Las operaciones terminales, como anyMatch, allMatch, noneMatch, findFirst, findAny, forEach, collect, count, reduce, min, max, y forEachOrdered, producen un resultado final o realizan una acción final en los elementos del Stream.

Al aprovechar las operaciones de stream, puedes escribir código más conciso, legible y eficiente cuando trabajas con colecciones de datos en Java.

00.02 Descarga de archivos de Internet

• 1. Introducción
• 2. Java IO
• 3. Java NIO

1. Introducción

Muchos de los siguientes ejercicios trabajan con archivos JSON de APIs JSON públicas o abiertas de Internet.

Existen varios modos de acceder a recursos, archivos, de Internet:

• Java IO.
• Java NIO.
• Bibliotecas externas como AsyncHttpClient y Apache Commons IO.

2. Java IO

La API más básica que podemos usar para descargar un archivo es Java IO. Podemos utilizar la clase URL para abrir una conexión al archivo que queremos descargar.

Para leer de manera eficaz el archivo, podemos utilizar el método openStream() para obtener un InputStream:

BufferedInputStream in = new BufferedInputStream(
    new URL(FILE_URL).openStream())

o:

URL url = new URL(FILE_URL);
URLConnection conn = url.openConnection();

BufferedReaderBufferedReader br = new BufferedReader(
                   new InputStreamReader(conn.getInputStream()));

La ventaja de este método es que podemos pasarle parámetros (cookies, tokens, identificadores de sesión…) a la cabecera HTTP:

URL url = new URL(FILE_URL);
HttpURLConnection urlc = (HttpURLConnection) url.openConnection(); 
urlc.setInstanceFollowRedirects(true);
urlc.setRequestProperty("User-Agent", "");
urlc.connect();

BufferedReader in = 
new BufferedReader(new InputStreamReader(urlc.getInputStream()));

Al leer desde un InputStream, se recomienda encapsularlo en un BufferedInputStream para aumentar el rendimiento.

Como hemos visto, la mejora de rendimiento proviene del almacenamiento en búfer. Al leer un byte a la vez mediante el método read(), cada llamada al método implica una llamada al sistema al sistema de archivos subyacente. Cuando la JVM invoca la llamada al sistema read(), el contexto de ejecución del programa cambia de modo usuario a modo kernel y viceversa. Este cambio de contexto es costoso desde una perspectiva de rendimiento. Al leer un gran número de bytes, el rendimiento de la aplicación será deficiente debido al gran número de cambios de contexto involucrados.

Para escribir los bytes leídos desde la URL en nuestro archivo local, utilizaremos el método write() de la clase FileOutputStream:

try (BufferedInputStream in = new BufferedInputStream(
    new URL(FILE_URL).openStream());
    FileOutputStream fileOutputStream = 
        new FileOutputStream(FILE_NAME)) {
    byte dataBuffer[] = new byte[1024];
    int bytesRead;
    while ((bytesRead = in.read(dataBuffer, 0, 1024)) != -1) {
        fileOutputStream.write(dataBuffer, 0, bytesRead);
    }
} catch (IOException e) {
    // gestión de la excepción
}

Cuando se utiliza un BufferedInputStream, el método read() leerá tantos bytes como hayamos establecido para el tamaño del búfer. En nuestro ejemplo, ya estamos haciendo esto al leer bloques de 1024 bytes a la vez, por lo que BufferedInputStream no es necesario. Para archivos JSON, como son archivos de texto, precisamos convertir el flujo entrada (InputStream) en un Reader por medio de la clase InputStreamReader, pasando a leer línea a línea.

Muchos métodos de procesado de archivos JSON (fromJson, parse,…) tienen una versión sobrecargada que recoge un Reader además de un String.

3. Java NIO

En el caso anterior, bajamos a nivel de flujo pero, como hemos estudiado, a partir de Java 7, se dispone de la clase Files que contiene métodos auxiliares para manejar operaciones de entrada/salida (IO).

Se puede utilizar el método Files.copy() para leer todos los bytes de un InputStream y copiarlos a un archivo local:

InputStream in = new URL(FILE_URL).openStream();
Files.copy(in, Paths.get(FILE_NAME), 
              StandardCopyOption.REPLACE_EXISTING);

El ejemplo anterior funciona bien, pero puede mejorarse. El principal ¿inconveniente? es que los bytes se almacenan en búfer en la memoria.

Java NIO tiene métodos para transferir bytes directamente entre dos canales sin almacenamiento en búfer.

El paquete Java NIO ofrece la posibilidad de transferir bytes entre dos canales sin almacenarlos en el espacio de memoria de la aplicación.

Para leer el archivo desde nuestra URL, crearemos un ReadableByteChannel a partir del flujo de URL:

ReadableByteChannel readableByteChannel =
         Channels.newChannel(url.openStream());

Los bytes leídos del ReadableByteChannel se transferirán a un FileChannel correspondiente al archivo que se va a descargar:

FileOutputStream fileOutputStream = new FileOutputStream(FILE_NAME);
FileChannel fileChannel = fileOutputStream.getChannel();

Puede usarse el método transferFrom() de la clase ReadableByteChannel para descargar los bytes desde la URL dada a nuestro FileChannel:

fileChannel.transferFrom(readableByteChannel, 
                0, Long.MAX_VALUE);

Los métodos transferTo() y transferFrom() son más eficientes que simplemente leer desde un flujo utilizando un búfer. Dependiendo del sistema operativo subyacente, los datos pueden transferirse directamente desde la caché del sistema de archivos a nuestro archivo sin copiar ningún byte en el espacio de memoria de la aplicación.

En sistemas Linux y UNIX, estos métodos utilizan la técnica de copia cero que reduce el número de cambios de contexto entre el modo kernel y el modo usuario.

03 Implementación de hashCode()

• Sobreescribe hashCode cuando sobreescribes equals

Sobreescribe hashCode cuando sobreescribes equals

Debes seimpre sobreescribir hashCode en cada clase que sobrescriba equals. Si no lo haces se violará el contrato general de hashCode, lo que hará que NO funcione correctamente en colecciones como HashMap y HashSet. Aquí está el contrato, adaptado de la especificación de Object:

• Cuando se invoca el método hashCode en un objeto repetidamente durante la ejecución de una aplicación, debe devolver consistentemente el mismo valor, siempre que la información utilizada en las comparaciones de equals no se modifique. Este valor no necesita ser consistente de una ejecución de una aplicación a otra.

• Si dos objetos son iguales según el método equals(Object), llamar a hashCode en los dos objetos debe producir el mismo resultado entero.

• Si dos objetos son diferentes según el método equals(Object), no es necesario que llamar a hashCode en cada uno de los objetos produzca resultados distintos. Sin embargo, el programador debe ser consciente de que producir resultados distintos para objetos diferentes puede mejorar el rendimiento de las tablas hash.

La disposición clave que se viola cuando no se sobrescribe hashCode es la segunda: los objetos iguales deben tener códigos hash iguales.
Dos instancias distintas pueden ser lógicamente iguales según el método equals de una clase, pero el método hashCode de Object, son sólo dos objetos con poco en común. Por lo tanto, el método hashCode de Object devuelve dos números aparentemente aleatorios en lugar de dos números iguales, como exige el contrato.

Por ejemplo, añadimos una instancia de la clase NumeroTelefono como clave en un HashMap:

Map<NumeroTelefono, String> m = new HashMap<>();
m.put(new NumeroTelefono(707, 867, 5309), "Otto");

En este punto, podrías esperar que m.get(new NumeroTelefono(707, 867, 5309)) devuelva “Otto”, pero en cambio, devuelve null. Observa que hay dos instancias de NumeroTelefono involucradas: una se utiliza para la inserción en el HashMap, y una segunda instancia igual se utiliza para la recuperación (intentada). La falta de sobrescritura de hashCode en la clase NumeroTelefono hace que las dos instancias iguales tengan códigos hash diferentes, violando el contrato de hashCode. Por lo tanto, es probable que el método get busque el número de teléfono en una tabla hash diferente al que fue almacenado por el método put. Incluso si las dos instancias resultan en el mismo cubo hash, es muy probable que el método get devuelva null, porque HashMap tiene una optimización que almacena en caché el código hash asociado con cada entrada y no se molesta en verificar la igualdad de objetos si los códigos hash no coinciden.

Para solucionar este problema, es tan sencillo como escribir un método hashCode adecuado para NumeroTelefono. Entonces, ¿cómo debería implementarse un método hashCode? Es fácil escribir uno malo. Este, por ejemplo, siempre es legal pero nunca debería ser usado:

// La peor implementación legal posible de hashCode: ¡nunca uses esto!
@Override
public int hashCode() {
    return 42;
}

Es legal porque asegura que los objetos iguales tengan el mismo código hash. Es muy nmalo porque asegura que cada objeto tenga el mismo código hash. Por lo tanto, cada objeto se asigna a la misma tabla hash, y las tablas hash degeneran en listas enlazadas. Los programas que deberían ejecutarse en tiempo lineal en su lugar se ejecutan en tiempo cuadrático. Para tablas hash grandes, esta es la diferencia entre funcionar y no funcionar.

Una buena función de hash tiende a producir códigos hash diferentes para instancias diferentes. Esto es exactamente lo que se entiende por la tercera parte del contrato de hashCode. Idealmente, una función de hash debería distribuir uniformemente cualquier colección razonable de instancias diferentes en todos los valores int. Lograr este ideal puede ser difícil, pero afortunadamente, no es demasiado difícil lograr una aproximación justa. Aquí tienes una receta sencilla:

1. Declara una variable int llamada resultado y inicialízala con el código hash c para el primer campo significativo en tu objeto, calculado en el paso 2.1. (Un campo significativo es un campo que afecta las comparaciones de equals).

2. Para cada campo significativo restante f en tu objeto, realiza lo siguiente:

   1. 2.1 Calcula un código hash c para el campo:
      1. i. Si el campo es de un tipo primitivo, calcula Type.hashCode(f), donde Type es la clase primitiva encapsulada correspondiente al tipo de f.
      2. Si el campo es una referencia a un objeto y el método equals de esta clase compara el campo mediante la invocación recursiva de equals, invoca recursivamente hashCode en el campo. Si se requiere una comparación más compleja, calcula una “representación canónica” para este campo e invoca hashCode en la representación canónica. Si el valor del campo es null, utiliza 0 (u otra constante, pero 0 es tradicional).
      3. Si el campo es un array, trátalo como si cada elemento significativo fuera un campo separado. Es decir, calcula un código hash para cada elemento significativo aplicando estas reglas recursivamente y combina los valores según el paso 2.b. Si el array no tiene elementos significativos, utiliza una constante, preferiblemente no 0. Si todos los elementos son significativos, utiliza Arrays.hashCode.
   2. Combina el código hash c calculado en el paso 2.a en resultado de la siguiente manera:

   resultado = 31 * resultado + c;

3. Devuelve resultado.

Cuando hayas terminado de escribir el método hashCode, pregúntate a ti mismo si las instancias iguales tienen códigos hash iguales. Escribe pruebas unitarias para verificar tu intuición (a menos que hayas utilizado AutoValue para generar tus métodos equals y hashCode, en cuyo caso puedes omitir estas pruebas de manera segura). Si las instancias iguales tienen códigos hash diferentes, averigua por qué y soluciona el problema.

Puedes excluir campos derivados del cálculo del código hash. En otras palabras, puedes ignorar cualquier campo cuyo valor pueda calcularse a partir de campos incluidos en el cálculo. Debes excluir cualquier campo que no se utilice en comparaciones de equals, o corres el riesgo de violar la segunda disposición del contrato de hashCode.

La multiplicación en el paso 2.b hace que el resultado dependa del orden de los campos, lo que produce una función de hash mucho mejor si la clase tiene múltiples campos similares. Por ejemplo, si se omitiera la multiplicación de una función de hash de String, todos los anagramas tendrían códigos hash idénticos. Se eligió el valor 31 porque es un número primo impar. Si fuera par y la multiplicación desbordara, se perdería información, ya que la multiplicación por 2 es equivalente a un desplazamiento. La ventaja de usar un número primo es menos clara, pero es tradicional. Una propiedad agradable del 31 es que la multiplicación se puede reemplazar por un desplazamiento y una resta para obtener un mejor rendimiento en algunas arquitecturas: 31 * i == (i << 5) - i. Las VM modernas realizan este tipo de optimización automáticamente.

Aplicaremos la receta anterior a la clase NumeroTelefono:

// Método típico de hashCode
@Override
public int hashCode() {
    int resultado = Short.hashCode(codigoArea);
    resultado = 31 * resultado + Short.hashCode(prefijo);
    resultado = 31 * resultado + Short.hashCode(numeroT);
    return resultado;
}

Dado que este método devuelve el resultado de un cálculo determinista simple cuyas únicas entradas son los tres campos significativos en una instancia de NumeroTelefono, es evidente que las instancias iguales de NumeroTelefono tienen códigos hash iguales. Este método es, de hecho, una implementación de hashCode perfectamente buena para NumeroTelefono, al nivel de las bibliotecas de plataformas Java. Es simple, bastante rápido y hace un trabajo razonable al dispersar números de teléfono diferentes en diferentes cubos hash.

Si bien esta estrategia produce funciones de hash bastante buenas, no son de última generación. Son comparables en calidad a las funciones de hash que se encuentran en los tipos de valor de las bibliotecas de plataformas Java y son adecuadas para la mayoría de los usos. Si realmente necesitas funciones de hash menos propensas a producir colisiones, consulta la clase com.google.common.hash.Hashing de Guava [Guava].

La clase Objects tiene un método estático que recoge un número arbitrario de objetos y devuelve un código hash para ellos. Este método, llamado hash, te permite escribir métodos hashCode de una línea cuya calidad es comparable a los declarados anteriormente. Desafortunadamente, se ejecutan más lentamente porque implican la creación de un array para pasar un número variable de argumentos, así como el boxing y unboxing si alguno de los argumentos es de tipo primitivo. Este estilo de función de hash se recomienda sólo en situaciones donde el rendimiento no es crítico. Aquí tienes una función de hash para NumeroTelefono escrita utilizando esta técnica:

// Método hashCode de una línea - rendimiento mediocre
@Override
public int hashCode() {
    return Objects.hash(numeroT, prefijo, codigoArea);
}

Si una clase es inmutable y el costo de calcular el código hash es significativo, podrías considerar almacenar en caché el código hash en el objeto en lugar de recalcularlo cada vez que se solicita. Si crees que la mayoría de los objetos de este tipo se utilizarán como claves hash, deberías calcular el código hash cuando se crea la instancia. De lo contrario, podrías optar por inicializar perezosamente el código hash la primera vez que se invoca hashCode. Se requiere cierto cuidado para asegurar que la clase siga siendo segura para subprocesos en presencia de un campo inicializado de forma perezosa. Nuestra clase NumeroTelefono no merece este tratamiento, pero solo para mostrarte cómo se hace, aquí está. Ten en cuenta que el valor inicial para el campo hashCode (en este caso, 0) no debería ser el código hash de una instancia comúnmente creada:

// Método hashCode con caché de código hash inicializado perezosamente
private int hashCode; // Inicializado automáticamente a 0
@Override
public int hashCode() {
    int resultado = hashCode;
    if (resultado == 0) {
        resultado = Short.hashCode(codigoArea);
        resultado = 31 * resultado + Short.hashCode(prefijo);
        resultado = 31 * resultado + Short.hashCode(numeroT);
        hashCode = resultado;
    }
    return resultado;
}

No te dejes tentar a excluir campos significativos del cálculo del código hash para mejorar el rendimiento. Aunque la función de hash resultante puede ejecutarse más rápido, su baja calidad puede degradar el rendimiento de las tablas hash hasta el punto en que se vuelven inutilizables. En particular, la función de hash puede enfrentarse a una gran colección de instancias que difieren principalmente en las regiones que has elegido ignorar. Si esto sucede, la función de hash asignará todas estas instancias a unos pocos códigos hash, y los programas que deberían ejecutarse en tiempo lineal en su lugar se ejecutarán en tiempo cuadrático.

Esto no es solo un problema teórico. Antes de Java 2, la función de hash de String utilizaba como máximo dieciséis caracteres distribuidos uniformemente en toda la cadena, comenzando por el primer carácter. Para grandes colecciones de nombres jerárquicos, como las URL, esta función mostraba exactamente el comportamiento patológico descrito anteriormente.

No proporciones una especificación detallada para el valor devuelto por hashCode, de modo que los clientes no puedan depender razonablemente de él; esto te da la flexibilidad para cambiarlo. Muchas clases en las bibliotecas de Java, como String e Integer, especifican el valor exacto devuelto por su método hashCode como una función del valor de la instancia. Esto no es una buena idea, sino un error con el que nos vemos obligados a vivir: obstaculiza la capacidad de mejorar la función de hash en futuras versiones. Si dejas los detalles sin especificar y se encuentra un defecto en la función de hash o se descubre una función de hash mejor, puedes cambiarla en una versión posterior.

En resumen, debes sobrescribir hashCode cada vez que sobres equals, o tu programa no funcionará correctamente. Tu método hashCode debe obedecer el contrato general especificado en Object y debe hacer un trabajo razonable asignando códigos hash diferentes a instancias diferentes. Esto es fácil de lograr, aunque ligeramente tedioso, utilizando la receta en la página 51. Como se menciona en el Ítem 10, el framework AutoValue proporciona una excelente alternativa para escribir manualmente los métodos equals y hashCode, y los IDE también ofrecen parte de esta funcionalidad.

01 Ventanas de entrada de datos, mensajes y archivos

• Ventanas de diálogo con Swing
  • 1. Paquetes principales del API
  • 2. Componentes de Swing
  • 3. JOptionPane
    • showMessageDialog
    • showInputDialog
  • 4. JFileChooser
    • Directorio de trabajo
    • Selección de archivos y/o directorios
    • Filtros de archivos

Ventanas de diálogo con Swing

JFC (Java Foundation Classes) es un conjunto de funciones/clases para crear interfaces gráficas de usuario (GUI) y añadir funcionalidad gráfica e interactividad a las aplicaciones Java que estudiaréis en la materia de Desenvolvemento de Interfaces.

Incluye: componentes gráficos de Swing (botones, paneles, tablas, ventanas, etc.), configuración de apariencia, API Java 2D, API de accesibilidad (lectores de pantalla, Braille,…); internacionalización (gestión de idiomas del mundo, …)

En la materia de Acceso a Datos vamos a dar una pequeña introducción a dos componentes de diálogo que nos facilitarán la introducción de datos en la primera parte, mostrar mensajes o selección de ficheros hasta que lo estudiéis en otras materias:

• JOptionPane:
  • https://docs.oracle.com/en/java/javase/22/docs/api/java.desktop/javax/swing/JOptionPane.html
• JFileChooser
  • https://docs.oracle.com/en/java/javase/22/docs/api/java.desktop/javax/swing/JFileChooser.html

Una ventana de diálogo es una subventana independiente destinada a llevar un aviso temporal además de la ventana principal de la aplicación Swing.

Suelen usarse para mostrar mensajes de error o una advertencia, presentar imágenes, árboles de directorios, etc.

Para facilitar el trabajo, existen las clases de utilidad:

• JOptionPane para crear ventanas de diálogo estándar y sencillos.
• Barras de progreso: JProgressBar (ver también ProgressMonitor)
• Elección de color: JColorChooser.
• Selección de archivos: JFileChooser.
• Diálogos de impresión: API de impresión.

1. Paquetes principales del API

• javax.swing
• javax.swing.event

Además de:

2. Componentes de Swing

3. JOptionPane

JOptionPane permite crear y personalizar rápidamente varios tipos diferentes de cuadros de diálogo.

Proporciona soporte para diseñar cuadros de diálogo estándar, con iconos, especificar el título y el texto del cuadro de diálogo y personalizar el texto del botón.

La compatibilidad con iconos de le permite especificar fácilmente qué icono muestra el cuadro de diálogo.

Son modales, esto es, bloquea el acceso a la ventana padre.

Puede utilizar un icono personalizado, ningún icono o cualquiera de los cuatro iconos estándar:

Cada apariencia tiene sus propias versiones de los cuatro íconos estándar.

La forma más sencilla de crear y mostrar diálogos con JOptionPane es por medio de los métodos showXxxDialog:

Existe una versión para marcos internos, JInternalFrame con métodos de la forma: showInternalXxxx

El formato del mensaje tiene una apariencia siguiendo la siguiente estructura:**

Los parámetros de los método showXxxDialog son los siguientes:

• parentComponent: componente padre, el JFrame. Si el valor es null, se usa el JFrame por defecto y se centra en la pantalla.

• mensaje: mensaje de la ventana de diálogo. Normalmente String, pero puede ser cualquier objeto:

  • Object[]: será interpretado como una serie de mensajes (uno por objeto) situados en vertical.
  • Component: mostrará el componente en la ventana de diálogo.
  • Icon: el icono será mostrado dentro de un JLabel.
  • Otros: se convierten a String llamando al método toString() y mostrándolo dentro de un JLabel.

• Título: título de la ventana.

• messageType: define el estilo del mensaje. Los posibles valores son:

  • ERROR_MESSAGE
  • INFORMATION_MESSAGE
  • WARNING_MESSAGE
  • QUESTION_MESSAGE
  • PLAIN_MESSAGE

• optionType: conjunto botones de opción que aparen debajo de la ventana. Se pueden proporcionar otro botones usando el parámetro options.

  • DEFAULT_OPTION
  • YES_NO_OPTION
  • YES_NO_CANCEL_OPTION
  • OK_CANCEL_OPTION

• options: es una descripción más detallada del conjunto de botones que aparecen en la parte inferior de la ventana. Lo usual es un array de String, pero puede ser un array de Object:

  • Component: el componente se añade a la lista de botones.
  • • Icon: se crea un JButton con este icono.
  • Otros: el objeto se convierte en String (toString()) y se emplea como etiqueta del botón.

• Icono: icono de la ventana de diálogo. El valor por defecto está determinado por el tipo de mensaje.

• initialValue: valor por defecto para ventanas de tipo input.

Los métodos showXxxDialog devuelven un entero, cuyos valores posibles son las constantes que referencian al botón pulsado:

• YES_OPTION
• NO_OPTION
• CANCEL_OPTION
• OK_OPTION
• CLOSED_OPTION

Object[] opcionesBoton = {"Sí, por supuesto", "No, gracias", "No estoy loco!"};
int resultado = JOptionPane.showOptionDialog(this, "¿Te has vacunado de COVID?", // mensaje
    "Una pregunta impertinente", // título
        JOptionPane.YES_NO_CANCEL_OPTION, // OptionType
        JOptionPane.QUESTION_MESSAGE, // Tipo de mensaje null, // icono
        opcionesBoton,
            opcionesBoton[2]); // valor por defecto

showMessageDialog

showMessageDialog : muestra un mensaje simple con un botón. (this es la referencia al formulario)

JOptionPane.showMessageDialog(this, "Hola Pepe",
                                      "Un saludo a Harry Haller",
                              JOptionPane.INFORMATION_MESSAGE);

Con título e icono por defecto:

JOptionPane.showMessageDialog(this, "Ovos fritidos con paracas.");

Con título, icono de aviso:

JOptionPane.showMessageDialog(this, "Arroz con chícharos.", "Aviso", JOptionPane.WARNING_MESSAGE);

Con título, icono de error:

JOptionPane.showMessageDialog(this, "Repolo de Vimianzo.", "Erro", JOptionPane.ERROR_MESSAGE);

Con título, sin icono:

JOptionPane.showMessageDialog(this, "Caldo galego.", "Nada", JOptionPane.PLAIN_MESSAGE);

Con título, icono personalizado:

ImageIcon icoSalada = new ImageIcon( getClass().getResource("/images/ensalada.png"));
JOptionPane.showMessageDialog(this, "Salada con verde.", "Primeiro prato", JOptionPane.INFORMATION_MESSAGE,  iconaSalada);

showInputDialog

showInputDialog : es el único método showXxxDialog que no devuelve un entero.

Devuelve un objeto, normalmente un String:

Object[] platoFavorito = {"chícharos", "doce", "churros"};
String s = (String)JOptionPane.showInputDialog(this, "o meu prato favorito é: ", 
        "Introduce tu plato favorito", JOptionPane.PLAIN_MESSAGE, iconaSalada, platoFavorito, "churros");

Si ponemos null en el array de opciones aparecerá una caja de texto:

Devuelve un objeto, normalmente un String:

String s = (String)JOptionPane.showInputDialog(this,
    "o meu prato favorito é: ", "Introduce tu plato favorito", JOptionPane.PLAIN_MESSAGE, iconaSalada,
    null,  "churros");

4. JFileChooser

Los selectores de archivos proporcionan una GUI para navegar por el sistema de archivos y luego elegir un archivo o directorio de una lista, o introducir el nombre de un archivo o directorio.  Normalmente usa la clase JFileChooser para mostrar un cuadro de diálogo modal que contiene el selector de archivos. Otra forma de presentar un selector de archivos es agregar una instancia de JFileChooser a un contenedor (ventana etc)

Ejemplo:

JFileChooser fc = new JFileChooser();
int returnVal = fc.showOpenDialog(this);

if (returnVal == JFileChooser.APPROVE_OPTION) {
    File file = fc.getSelectedFile();
    // Esto es lo que se hace con el archivo seleccionado
} else {
    // Esto es lo que se hace si se cancela la selección
}

El método showOpenDialog muestra un cuadro de diálogo para abrir un archivo.

El método showSaveDialog muestra un cuadro de diálogo para guardar un archivo.

JFileChooser fcImaxe = new JFileChooser();
FileNameExtensionFilter filtro 
        = new FileNameExtensionFilter("Imágenes JPG y PNG", "jpg", "png");
fcImaxe.setFileFilter(filtro);
int valorSel = fcImaxe.showOpenDialog(null);
if (valorSel == JFileChooser.APPROVE_OPTION){
    System.out.println("Has seleccionado la imagen:" + fcImaxe.getSelectedFile().getName());
}

Directorio de trabajo

showOpenDialog recoge el componente padre de la ventana de diálogo y afecta a la posición de la ventana de diálogo.

Por defecto muestra los archivos del directorio de trabajo del usuario, pero puede especificarse el directorio inicial de varios modos:

• En el constructor:

JFileChooser fc = new JFileChooser("e:\\");

• Por medio del método:

fc.setCurrentDirectory(new File("e:\\"));

Selección de archivos y/o directorios

showOpenDialog/showSaveDialog recoge devuelven un entero que indica si se ha seleccionado un archivo: APPROVE_OPTION o CANCEL_OPTION

Una vez seleccionado un archivo o directorio (en ese caso debe indicarse que se permite selección de directorios) puede invocarse al método getSelectedFile() para recuperar el archivo (File):

File arquivo = fcImaxe.getSelectedFile();

Una vez recuperado el archivo podemos obtener muchos datos del mismo (lo veremos en la unidad de archivos):

File arquivo = fcImaxe.getSelectedFile();
arquivo.getPath();
arquivo.getName();
arquivo.isDirectory();
arquivo.exists();
arquivo.delete();
// ...

Se puede utilizar la misma instancia de la JFileChooser para mostrar un cuadro de diálogo estándar para guardar.

int valor = fc.showSaveDialog(null);

Al utilizar la misma instancia del JFileChooser:

• Recuerda el directorio actual entre usos, por lo que las versiones para abrir y guardar comparten automáticamente el mismo directorio actual.
• Sólo se personaliza un selector de archivos, y las personalizaciones se aplican tanto a la versión para abrir como para guardar.

Se puede cambiar el modo de selección de archivos, por ejemplo para seleccionar directorios:

fc.setFileSelectionMode(JFileChooser.DIRECTORIES_ONLY);

Además, existen otros modos de selección:

• FILES_AND_DIRECTORIES.
• FILES_ONLY (por defecto).
• DIRECTORIES_ONLY.

Filtros de archivos

Por defecto, el JFileChooser muestra todos los archivos y directorios, excepto los ocultos.

Pueden programarse filtros de archivos para escoger algún tipo de archivo o directorio.

El JFileChooser llama al método accept (de FileFilter) determina qué se mostrará.

Existen varios tipos de filtros:

• setFileHidingEnabled(false): para mostrar los archivos ocultos.
• Subclases de la clase abstracta FileFilter: FileNameExtensionFilter: https://docs.oracle.com/en/java/javase/22/docs/api/java.desktop/javax/swing/filechooser/FileNameExtensionFilter.html

FileFilter filtro = new FileNameExtensionFilter("archivo JPEG", "jpg", "jpeg");
 JFileChooser fc; // = ...;
 fc.setFileFilter(filtro);
// fc.addChoosableFileFilter(filtro); // agrega a los seleccionables.
// fc. setAcceptAllFileFilterUsed(false);

05 GridBagLayout

GridBagLayout

Cómo usar GridBagLayout

GridBagLayout es uno de los gestores de diseño más flexibles —y complejos— que proporciona la plataforma Java. Un GridBagLayout coloca componentes en una cuadrícula de filas y columnas, permitiendo que los componentes especificados abarquen múltiples filas o columnas. No todas las filas necesariamente tienen la misma altura. Del mismo modo, no todas las columnas necesariamente tienen el mismo ancho. Esencialmente, GridBagLayout coloca los componentes en rectángulos (celdas) en una cuadrícula y luego utiliza los tamaños preferidos de los componentes para determinar qué tan grandes deben ser las celdas.

La forma en que el programa especifica las características de tamaño y posición de sus componentes es especificando restricciones para cada componente. El enfoque preferido para establecer restricciones en un componente es usar la variante de Container.add, pasándole un objeto GridBagConstraints.

GridBagLayout y GridBagConstraints

GridBagConstraints es una clase que especifica cómo se colocan los componentes en un GridBagLayout. Cada componente que se agrega a un contenedor con un GridBagLayout debe tener su propio objeto GridBagConstraints.

GridBagConstraints tiene muchas propiedades que se pueden establecer para controlar cómo se coloca un componente en un GridBagLayout. Algunas de las propiedades más comunes son:

• gridx, gridy: la posición de la celda en la cuadrícula donde se colocará el componente.
• gridwidth, gridheight: el número de celdas en la cuadrícula que el componente debe ocupar en la dirección horizontal y vertical.
• weightx, weighty: la cantidad de espacio adicional que se asigna a la celda en la dirección horizontal y vertical.
• fill: cómo el componente debe llenar la celda si la celda es más grande que el componente.
• anchor: cómo el componente debe ser posicionado en la celda si la celda es más grande que el componente.
• insets: el espacio adicional que se debe agregar alrededor del componente.
• ipadx, ipady: el espacio adicional que se debe agregar alrededor del componente en la dirección horizontal y vertical.

Por ejemplo, el siguiente código Swing crea un GridBagLayout con un botón en la esquina superior izquierda de la cuadrícula:

import java.awt.*;
import javax.swing.*;

public class GridBagLayoutExample {
    public static void main(String[] args) {
        JFrame frame = new JFrame("Ejemplo de GridBagLayout");
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

        JPanel panel = new JPanel(new GridBagLayout());
        frame.add(panel);

        JButton button = new JButton("Button");
        GridBagConstraints constraints = new GridBagConstraints();
        constraints.gridx = 0;
        constraints.gridy = 0;
        panel.add(button, constraints);

        frame.setSize(300, 200);
        frame.setVisible(true);
    }
}

En este ejemplo, se crea un GridBagLayout y se agrega un botón al panel. El botón se coloca en la esquina superior izquierda de la cuadrícula, ya que gridx y gridy se establecen en 0.

También podríamos crear un rejilla de 3x3 y añadir un botón en la posición (1,1) de la cuadrícula:

import java.awt.*;

import javax.swing.*;

public class GridBagLayoutExample {
    public static void main(String[] args) {
        JFrame frame = new JFrame("Ejemplo de GridBagLayout");
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

        JPanel panel = new JPanel(new GridBagLayout());
        frame.add(panel);

        JButton button = new JButton("Button");
        GridBagConstraints constraints = new GridBagConstraints();
        constraints.gridx = 1;
        constraints.gridy = 1;
        panel.add(button, constraints);

        frame.setSize(300, 200);
        frame.setVisible(true);
    }
}

En este caso, el botón se coloca en la posición (1,1) de la cuadrícula, ya que gridx y gridy se establecen en 1.

Otro ejemplo más complejo podría ser el siguiente:

import java.awt.*;
import javax.swing.*;

public class GridBagLayoutExample {
    public static void main(String[] args) {
        JFrame frame = new JFrame("Ejemplo de GridBagLayout");
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

        JPanel panel = new JPanel(new GridBagLayout());
        frame.add(panel);

        JButton button1 = new JButton("Button 1");
        GridBagConstraints constraints1 = new GridBagConstraints();
        constraints1.gridx = 0;
        constraints1.gridy = 0;
        panel.add(button1, constraints1);

        JButton button2 = new JButton("Button 2");
        GridBagConstraints constraints2 = new GridBagConstraints();
        constraints2.gridx = 1;
        constraints2.gridy = 0;
        panel.add(button2, constraints2);

        JButton button3 = new JButton("Button 3");
        GridBagConstraints constraints3 = new GridBagConstraints();
        constraints3.gridx = 0;
        constraints3.gridy = 1;
        constraints3.gridwidth = 2;
        panel.add(button3, constraints3);

        frame.setSize(300, 200);
        frame.setVisible(true);
    }
}

En este ejemplo, se crean tres botones y se agregan al panel. El primer botón se coloca en la posición (0,0) de la cuadrícula, el segundo botón se coloca en la posición (1,0) de la cuadrícula y el tercer botón se coloca en la posición (0,1) de la cuadrícula y ocupa dos celdas en la dirección horizontal.

Por último, podemos crear un rejilla de dos filas y hacer que la segunda columna ocupe dos celdas en la dirección vertical:

import java.awt.*;
import javax.swing.*;

public class GridBagLayoutExample {
    public static void main(String[] args) {
        JFrame frame = new JFrame("Ejemplo de GridBagLayout");
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

        JPanel panel = new JPanel(new GridBagLayout());
        frame.add(panel);

        JButton button1 = new JButton("Button 1");
        GridBagConstraints constraints1 = new GridBagConstraints();
        constraints1.gridx = 0;
        constraints1.gridy = 0;
        panel.add(button1, constraints1);

        JButton button2 = new JButton("Button 2");
        GridBagConstraints constraints2 = new GridBagConstraints();
        constraints2.gridx = 1;
        constraints2.gridy = 0;
        panel.add(button2, constraints2);

        JButton button3 = new JButton("Button 3");
        GridBagConstraints constraints3 = new GridBagConstraints();
        constraints3.gridx = 0;
        constraints3.gridy = 1;
        constraints3.gridheight = 2;
        panel.add(button3, constraints3);

        frame.setSize(300, 200);
        frame.setVisible(true);
    }
}

En este ejemplo, se crean tres botones y se agregan al panel. El primer botón se coloca en la posición (0,0) de la cuadrícula, el segundo botón se coloca en la posición (1,0) de la cuadrícula y el tercer botón se coloca en la posición (0,1) de la cuadrícula y ocupa dos celdas en la dirección vertical.

anchor y fill

Además de las propiedades gridx, gridy, gridwidth, gridheight, weightx, weighty, insets, ipadx e ipady, GridBagConstraints también tiene las propiedades anchor y fill.

La propiedad anchor controla cómo se posiciona un componente en su celda si la celda es más grande que el componente. Los valores posibles para anchor son:

• GridBagConstraints.FIRST_LINE_START (GridBagConstraints.NORTHWEST): el componente se coloca en la esquina superior izquierda de la celda.

• GridBagConstraints.PAGE_START (GridBagConstraints.NORTH): el componente se coloca en la parte superior de la celda.

• GridBagConstraints.FIRST_LINE_END (GridBagConstraints.NORTHEAST): el componente se coloca en la esquina superior derecha de la celda.

• GridBagConstraints.LINE_START (GridBagConstraints.WEST): el componente se coloca en el lado de inicio de la celda (izquierda en un contenedor de izquierda a derecha, derecha en un contenedor de derecha a izquierda).

• GridBagConstraints.CENTER: el componente se coloca en el centro de la celda.

• GridBagConstraints.LINE_END (GridBagConstraints.EAST): el componente se coloca en el lado final de la celda (derecha en un contenedor de izquierda a derecha, izquierda en un contenedor de derecha a izquierda).

• GridBagConstraints.LAST_LINE_START (GridBagConstraints.SOUTHWEST): el componente se coloca en la esquina inferior izquierda de la celda.

• GridBagConstraints.PAGE_END (GridBagConstraints.SOUTH): el componente se coloca en la parte inferior de la celda.

• GridBagConstraints.LAST_LINE_END (GridBagConstraints.SOUTHEAST): el componente se coloca en la esquina inferior derecha de la celda.

• GridBagConstraints.BASELINE: el componente se coloca en la línea base de la celda.

• GridBagConstraints.BASELINE_LEADING: el componente se coloca en la línea base de inicio de la celda.

• GridBagConstraints.BASELINE_TRAILING: el componente se coloca en la línea base de final de la celda.

Conclusión

GridBagLayout es un gestor de diseño muy flexible que permite colocar componentes en una cuadrícula de filas y columnas. Al utilizar GridBagConstraints, se pueden controlar las propiedades de tamaño y posición de los componentes en la cuadrícula. Aunque GridBagLayout puede ser complejo de usar, ofrece una gran flexibilidad para diseñar interfaces de usuario complejas y personalizadas.

01. Principios de diseño

• Introducción
• Encapsulación de Datos
  • Bloqueo de acceso directo a atributos privados
• Creación de JavaBeans
• Relación Es‐un
• Relación Tiene‐un
  • Problemas del modelo de datos empleando Es‐un y Tiene‐un
• Composición de Objetos

Introducción

Haremos un inciso para repasar y descubrir nuevos principios de diseño, pues son un elemento clave en el diseño de estructura de clases de acceso a Datos, patrones como Singleton son interesantes para establecer conexiones a BD, por ejemplo.

Un principio de diseño es una idea establecida o mejor práctica que facilita el proceso de diseño de software. Al crear clases en Java estos principios conducen a bases de código mejores y más manejables. En general, seguir buenos principios de diseño lleva a:

• Código más lógico
• Código más fácil de entender
• Clases más fáciles de reutilizar en otras relaciones y aplicaciones
• Código más fácil de mantener y que se adapta más fácilmente a cambios en los requisitos de la aplicación

Un modelo de datos es la representación de nuestros objetos y sus propiedades dentro de la aplicación y cómo se relacionan con elementos del mundo real.

Encapsulación de Datos

Un principio fundamental del diseño orientado a objetos es el concepto de encapsular datos.
En el desarrollo de software, la encapsulación es declarar que los atributos y métodos en una clase de manera que los métodos operen sobre los atributos, en lugar de que los usuarios de la clase accedan directamente a los atributos. En Java, de manera general se implementan con atributos de instancia privados que tienen métodos públicos para recuperar o modificar los datos, comúnmente conocidos como getters y setters, respectivamente.

public class EjemploClase {
    private int datos;

    // Método getter
    public int getDatos() {
        return datos;
    }

    // Método setter
    public void setDatos(int nuevosDatos) {
        this.datos = nuevosDatos;
    }
}

Ningún elemento además de la propia clase debería tener acceso directo a sus datos.

Se dice que la clase encapsula los datos que contiene y evita que alguien acceda directamente a ellos. Con la encapsulación, una clase puede mantener ciertas invariantes sobre sus datos internos. Una invariante es una propiedad o verdad que se mantiene incluso después de que los datos son modificados. Por ejemplo, imaginemos que estamos diseñando una nueva clase Animal y tenemos los siguientes requisitos de diseño:

• Cada animal tiene un campo de especie no nulo y no vacío.
• Cada animal tiene un campo de edad que es mayor o igual a cero.

El objetivo al diseñar nuestra clase Animal sería asegurarnos de que nunca lleguemos a una instancia de Animal que viole una de estas propiedades. Al usar miembros de instancia privados junto con métodos getter y setter que validan los datos de entrada, podemos garantizar que estas invariantes sigan siendo verdaderas.

Por ejemplo, si definimos la clase Animal sin encapsulación:

public class Animal {
    public String especie;
    public int edad;
}

Al definir la clase Animal de esta manera, es fácil crear una instancia de Animal que no cumpla las invariantes:

Animal animal = new Animal(); // La especie no debería ser nula.
animal.edad = -80; // La edad no podría ser negativa.

L primera invariante se viola tan pronto como se crea el objeto, con la especie predeterminada a nula. Luego, el usuario establece el campo de edad en -80, ya que este campo es accesible públicamente, lo que resulta en la violación de la segunda invariante.

HAciendo los atributos privados, la clase es la única que puede modificar los datos directamente. Al definir constructores, getters y setters que cumplan las condiciones:

public class Animal {
    private String especie;
    private int edad;

    public Animal(String especie) {
        this.setEspecie(especie);
    }

    public String getEspecie() {
        return especie;
    }

    public void setEspecie(String especie) {
        if(especie == null || especie.trim().length()==0) {
            throw new IllegalArgumentException("La especie es obligatoria");
        }
        this.especie = especie;
    }

    public int getAge() {
        return edad;
    }

    public void setAge(int edad) {
        if(edad < 0) {
            throw new IllegalArgumentException("La edad no puede ser un número negativo");
        }
        this.edad = edad;
    }
}

Las variables especie y edad están marcadas como privadas, con métodos públicos getEspecie() y getEdad() para leer los datos. Además, setEspecie() y setEdad() ahora validan la entrada y lanzan una excepción si se viola una de nuestras invariantes. Además, se ha añadido un constructor no predeterminado que requiere un valor de especie y utiliza el método setter para validar la entrada.

La ventaja de esta nueva implementación de la clase Animal es que utiliza la encapsulación para hacer cumplir los principios de diseño de la clase. Cada vez que se pasa una instancia de un objeto Animal a un método, se puede usar sin requerir que se validen sus invariantes.

Bloqueo de acceso directo a atributos privados

EN la práctica, los getter o setter a menudo ofrece un acceso casi directo a los atributos privados:

private String nombre;

public String getNombre() {
    return nombre;
}

public void setNombre(String nombre) {
    this.nombre = nombre;
}

Aunque puede parecer una mala encapsulación, el campo nombre se puede cambiar sin aplicar ninguna regla, es mucho mejor que permitir el acceso directo a la variable privada nombre. La ventaja radica en que fácilmente se puede actualizar el método getter o setter para tener reglas más complejas sin hacer que las otras clases que lo usan tengan que recompilar el código. El método setNombre() podría reescribirse de la siguiente manera:

public void setNombre(String nombre) {
    this.nombre = (nombre == null || nombre.trim().length() == 0) ? null : nombre;
}

Dado que la firma del método setNombre() no cambió, la invocación de este método no implica tener que modificar y recompilar su código.

Se considera una buena práctica de diseño encapsular siempre todas las variables en una clase, incluso si no hay reglas de datos establecidas, como una forma de proteger los datos cuando dichas reglas puedan añadirse en el futuro.

Creación de JavaBeans

La encapsulación es tan prevalente en Java que existe un estándar para crear clases que almacenan datos, llamado JavaBeans. Un JavaBean es un principio de diseño para encapsular datos en un objeto en Java;

Convenciones de nomenclatura de JavaBean:

Aunque los valores booleanos utilizan is para comenzar sus métodos getters, NO se aplica a las instancias de la clase envolvente Boolean, que utilizan get.

Por ejemplo:

private boolean jugando;
private Boolean bailando;

¿Cuál de las siguientes podría incluirse correctamente en un JavaBean?

public boolean isJugando() { return jugando; }
public boolean getJugando() { return jugando; }
public Boolean isBailando() { return bailando; }

La primera línea es correcta porque define un getter adecuado para una variable booleana. El segundo ejemplo también es correcto, ya que boolean puede usar is o get. La tercera línea es incorrecta, porque un envoltorio Boolean debería comenzar con get, ya que es un objeto.

public String nombre;
public String nombre() { return nombre; }
public void actualizarNombre(String n) { nombre = n; }
public void setnombre(String n) { nombre = n; }

¡Ninguna de estas líneas sigue las prácticas correctas de JavaBean! La primera línea hace público el nombre, cuando debería ser privado. La segunda línea no define un getter adecuado y debería ser getNombre(). Las dos últimas líneas son incorrectos setters, ya que la primera no comienza con set y la segunda no tiene la primera letra del nombre del atributo en mayúscula.

Relación Es‐un

El operador instanceof se puede usar para determinar cuándo un objeto es una instancia de una clase, superclase o interfaz particular. En el diseño orientado a objetos, se describe la relación de que un objeto es una instancia de un tipo de datos como tener una relación es‐un. La relación es‐un también se conoce como la prueba de herencia.

Cuando se construye un modelo de datos basado en la herencia, es importante aplicar la relación es‐un regularmente, para diseñar clases que conceptualmente tengan sentido. Por ejemplo, una clase Gato que hereda de una clase Mascota, como se muestra en la imagen:

classDiagram
    Mascota <|-- Gato

La clase principal, Mascota, tiene campos comunes como nombre y edad. Se podría incurrir en el error de diseñar una clase Tigre, y dado que los tigres también tienen una edad y un nombre, se podría estar tentado en reutilizar la clase principal Mascota con el propósito de ahorrar tiempo y líneas de código, dando lugar a diseños incorrectos:

classDiagram
    Mascota <|-- Gato
    Mascota <|-- Tigre

Por desgracias ;-), Mascota también tiene un método acariciar().
Al reutilizar la clase principal Mascota, se está afirmando conceptualmente que un Tigre es‐una Mascota, pero un Tigre no es una Mascota. Aunque este ejemplo es funcionalmente correcto y ahorra tiempo y líneas de código, el resultado de no aplicar la relación es‐un es que se ha creado una relación que viola el modelo de datos. Intentemos solucionar el problema colocando Mascota y Tigre debajo de una clase padre Felino y veamos si eso resuelve el problema:

classDiagram
    Felino <|-- Tigre
    Felino <|-- Mascota
    Mascota <|-- Gato
    Mascota <|-- Perro

La estructura de clases es ahora más coherente, pero si se añade un hijo Perro a Mascota, nos encontramos con un problema con la prueba es‐un. Un Perro es‐una Mascota, y una Mascota es‐una Felino, pero el modelo implica que un Perro es‐un Felino, lo cual obviamente no es cierto.

La prueba de relación es‐un ayuda a evitar crear modelos de objetos que contengan contradicciones. Una solución en este ejemplo sería no combinar Tigre y Mascota en el mismo modelo, prefiriendo escribir código duplicado en lugar de crear datos inconsistentes. Una mejor solución podría ser utilizar las propiedades de las interfaces y declarar Mascota como una interfaz en lugar de una clase principal:

classDiagram
    Animal <|-- Perro
    Animal <|-- Felino
    Felino <|-- Tigre
    Felino <|-- Gato
    Mascota <|.. Gato
    Mascota <|.. Perro

Ahora es correcto usando la prueba es‐un: Gato es‐un Animal, Tigre es‐un Felino, Perro es‐un Animal, y así sucesivamente. Mascota ahora está separada del modelo de herencia de clases, pero al usar interfaces, preservamos la relación de que Gato es‐una Mascota y Perro es‐una Mascota.

Relación Tiene‐un

En el diseño orientado a objetos, a menudo queremos probar si un objeto contiene una propiedad o valor en particular. La relación tiene‐un cuando la propiedad de una clase tiene un nombre de un objeto o primitiva como miembro. La relación tiene‐un también se conoce como la prueba de composición de objetos.

Por ejemplo, las clases Pájaro y Pico:

classDiagram
    Pato o-- Pico
    class Pico {
      -String color
      -double longitud
    }
    class Pato{
      -Pico pico
      -Pie pieDerecho
      -Pie pieIzquierdo
    }

Pájaro y Pico son clases con atributos y valores diferentes. Aunque obviamente fallan la prueba es‐un, ya que un Pájaro no es un Pico, ni un Pico es un Pájaro, sí pasan la prueba tiene‐un, ya que un Pájaro tiene un Pico. La herencia va un paso más allá al permitirnos decir que cualquier hijo de Pájaro también debe tener un Pico.

Problemas del modelo de datos empleando Es‐un y Tiene‐un

A veces, las relaciones parecen pasar la prueba es‐un pero fallan al combinarse con la relación tiene‐un a través de la herencia. Por ejemplo:

public class Cola {}
public class Primate {
    protected Cola cola;
}

public class Mono extends Primate { // El mono tiene una cola ya que es un primate
}
public class Chimpance extends Primate { // El chimpancé tiene una cola ya que es un primate
}

En el ejemplo, un Mono es‐un Primate y un Chimpance es‐un Primate. El modelo también establece que un Primate tiene‐una Cola, y mediante la herencia, un Mono tiene‐un Cola y un Chimpancé tiene‐un Cola. Sin embargo, los chimpancés no tienen cola, por lo que el modelo de datos subyacente es incorrecto.
Deberíamos eliminar la propiedad Cola de la clase Primates, ya que no todos los primates tienen colas.

Composición de Objetos

En el diseño orientado a objetos la composición de objetos es la propiedad de construir una clase utilizando referencias a otras clases para reutilizar la funcionalidad de esas clases.

La clase contiene las otras clases en el sentido de tiene‐un y puede delegar métodos a las otras clases.

La composición de objetos debe considerarse como una alternativa a la herencia y a menudo se utiliza para simular un comportamiento polimórfico que no se puede lograr mediante la herencia simple:

public class Aletas {
    public void aletear() {
        System.out.println("Las aletas se mueven de un lado a otro");
    }
}

public class PatasPalmeadas {
    public void patear() {
        System.out.println("Las patas palmeadas patean de un lado a otro");
    }
}

Intentar relacionar estos objetos mediante la herencia no tiene sentido, ya que las PatasPalmeadas no son lo mismo que las Aletas. En cambio, podemos crear una nueva clase que contenga ambas de estas clases y delegue sus métodos en ella:

public class Pingüino {
    private final Aletas aletas;
    private final PatasPalmeadas patasPalmeadas;

    public Pingüino() {
        this.aletas = new Aletas();
        this.patasPalmeadas = new PatasPalmeadas();
    }

    public void aletear() {
        this.aletas.aletear();
    }

    public void patear() {
        this.patasPalmeadas.patear();
    }
}

La clase Pingüino está compuesta por instancias de Aletas y PatasPalmeadas. La parte difícil de aletear() y patear() se delega a las otras clases, siendo los métodos en la clase Pingüino de solo una línea. Ten en cuenta que las implementaciones de estos métodos en las clases delegadas también tienen solo una línea, aunque podrían ser considerablemente más complejas.

Una de las ventajas de la composición de objetos sobre la herencia es que tiende a promover una mayor reutilización de código. Al utilizar la composición de objetos, se accede a otras clases y métodos que serían difíciles de obtener mediante el modelo de herencia simple.

En el ejemplo, la clase Aletas se puede reutilizar en clases completamente no relacionadas con un Pingüino o un Ave, como en una clase Delfín o Tortuga. Si la clase Aletas hubiera sido heredada de la clase Pingüino, entonces usarla en otras clases no relacionadas sería difícil sin romper el modelo de clases o tener que hacer que la otra clase contenga una instancia de un Pingüino. Por ejemplo, sería absurdo decir que un Delfín hereda de un Pingüino o tiene una instancia de una clase Pingüino, sólo porque un Delfín tiene Aletas y Aletas hereda de la clase Pingüino.

Por otro lado, sobrecarga de métodos para determinar dinámicamente qué método seleccionar en tiempo de ejecución es una herramienta muy útil.

02. Patrón Singleton

• 1. El Patrón Singleton
• 2. Tipos de implementación del patrón Singleton
  • 1. Inicialización en la decleración
  • 2. Usando bloques static
  • 3. Instanciación “perezosa” de Singleton
    • Singleton en varias computadoras
  • 4. Thread Safe Singleton
  • 5. Singletons con bloqueo de doble comprobación (Double‐Checked Locking)
• Conclusión

1. El Patrón Singleton

En muchos casos, precisamos crear un objeto en memoria sólo una vez en una aplicación y compartirlo entre varias clases. Un ejemplo podría ser una conexión a una base de datos, pero sucede con frecuenta con otro tipo de recursos compartidos.

Por ejemplo, podríamos querer gestionar la cantidad de comida disponible para la alimentación de los animales de un zoológico en todas las clases que lo utilizan. Podríamos pasar el mismo objeto compartido ComidaManager a cada clase y método que lo utiliza, aunque esto crearía muchos punteros adicionales y podría ser difícil de gestionar si el objeto se utiliza en toda la aplicación. Al crear un objeto singleton ComidaManager, centralizamos los datos y eliminamos la necesidad de pasarlos por toda la aplicación.

• El patrón singleton es un patrón de creación que permite sólo una instancia de un objeto en memoria dentro de una aplicación, compartida por todas las clases y hilos dentro de la aplicación.

• El objeto disponible globalmente creado por el patrón singleton se denomina objeto singleton.

• Los singleton también pueden mejorar el rendimiento cargando datos reutilizables que de otro modo serían costosos de almacenar y recargar cada vez que se necesitan.

Una implementación sencilla de clase ComidaManager con un patrón singleton básico:

public class AlmacenComida {

    private int cantidad = 0;

    private AlmacenComida() {} // Privado, se crea como atributo estático:

    private static final AlmacenComida instancia = new AlmacenComida(); // static: único.

    // Método público único para obtener la instancia:
    public static AlmacenComida getInstance() {
        return instancia;
    }

    public synchronized void addComida(int cantidad) {
        this.cantidad += cantidad;
    }

    public synchronized boolean removeComida(int cantidad) {
        if (this.cantidad < cantidad) return false;
        this.cantidad -= cantidad;
        return true;
    }

    public synchronized int getCantidadComida() {
        return cantidad;
    }
}

• Los singleton en Java se crean como atributos privados estáticos dentro de la clase, a menudo con el nombre instance (o instancia).
• Se accede a ellos a través de un único método público estático, a menudo llamado getInstance(), que devuelve la referencia al objeto singleton.
• Todos los constructores en una clase singleton se declaran como privados, lo que garantiza que ninguna otra clase pueda instanciar otra versión de la clase. Al marcar los constructores como privados, hemos marcado implícitamente la clase como final.

Recuerda que cada clase requiere al menos un constructor, con el constructor por defecto si no se proporciona ninguno. Además, la primera línea de cualquier constructor es una llamada a un constructor padre super(). Si todos los constructores se declaran privados en la clase singleton, entonces es imposible crear una subclase con un constructor válido; por lo tanto, la clase singleton es final.

• Se añade el modificador synchronized a addComida(), removeComida() y getCantidadComida(), para evitar que dos procesos ejecuten el mismo método exactamente al mismo tiempo y haya inconsistencias.

En el ejemplo AlmacenComida, un proceso que quiera usar este singleton primero llama a getInstance() y luego llama al método público necesario:

public class EntrenadorLlamas {

    public boolean alimentarLlamas(int numeroLlamas) {

        int cantidadNecesaria = 5 * numeroLlamas;

        AlmacenComida AlmacenComida = AlmacenComida.getInstance();

        if (AlmacenComida.getCantidadComida() < cantidadNecesaria) {
            AlmacenComida.addComida(cantidadNecesaria + 10);
        }

        boolean alimentadas = AlmacenComida.removeComida(cantidadNecesaria);

        if (alimentadas)
            System.out.println("Las llamas han sido alimentadas");
        return alimentadas;
    }

}

Un aspecto a tener en cuenta es que puede haber varias clases en la aplicación que requieran el objeto Singleton.
En el ejemplo, equivaldría a muchas instancias de EntrenadorLlamas pero sólo una instancia del objeto Singleton, AlmacenComida.
El boolean devuelto por removeComida(), permite comprobar si hay disponible.
En nuestro primer ejemplo de AlmacenComida, instanciamos el objeto singleton directamente en la definición de la referencia de instancia.

2. Tipos de implementación del patrón Singleton

Se puede instanciar un singleton de varios modos:

a) En la declaración del objeto:

private static final ClaseSingleton instancia = new ClaseSingleton();

b) Utilizando un bloque de inicialización estático:

    private static final ClaseSingleton instancia;

    static {
        instancia = new ClaseSingleton();
        // Realizar pasos adicionales
    }

c) Instanciación “perezosa” de Singleton. Se realiza en la primera llamada a la invocación del método getInstance:

    private static ClaseSingleton instancia;

    private ClaseSingleton() {
    }

    public static ClaseSingleton getInstance() {
        if (instancia == null) {
            instancia = new ClaseSingleton(); // ¡NO ES SEGURO PARA HILOS!
        }
        return instancia;
    }

Por ejemplo:

// Instanciación usando un bloque estático
public class RegistroPersonal {
    private static final RegistroPersonal instancia;

    static {
        instancia = new RegistroPersonal();
        // Realizar pasos adicionales
    }

    private RegistroPersonal() {
    }

    public static RegistroPersonal getInstance() {
        return instancia;
    }

    // Métodos de acceso a datos
    // ...
}

Tanto la clase RegistroPersonal como la clase anterior AlmacenComida instancian el singleton en el momento en que se carga la clase. Sin embargo, a diferencia de la clase AlmacenComida, la clase RegistroPersonal instancía el singleton como parte de un bloque de inicialización estático.

Aunque estas dos implementaciones son equivalentes, ya que ambas crean el singleton cuando se carga la clase, el bloque de inicialización estático permite realizar pasos adicionales para configurar el singleton después de que se ha creado. También permite gestionar casos en los que el constructor de RegistroPersonal lanza una excepción.
Dado que el singleton se crea cuando se carga la clase, permite marcar la como final, lo que garantiza que sólo se creará una instancia dentro de la aplicación.

Hay muchas formas de hacer esto en Java. Todas estas formas difieren en su implementación del patrón, pero al final, todas logran el mismo resultado final de una única instancia.

1. Inicialización en la decleración

Es el método más sencillo de crear una clase singleton. El objeto de la clase se crea cuando se carga en la memoria por la JVM, asignando directamente la referencia de una instancia.

Puede utilizarse cuando el programa siempre usará una instancia de esta clase, o el costo de crear la instancia no es demasiado grande en términos de recursos y tiempo.

// Código Java para crear una clase singleton mediante
// "Inicialización Ansiosa"
public class ClaseSingletonAD {
  // instancia pública inicializada al cargar la clase
  private static final ClaseSingletonAD instance = new ClaseSingletonAD();
 
  private ClaseSingletonAD() {
    // constructor privado
  }
  
  public static ClaseSingletonAD getInstance(){
    return instance;
  }
}

Ventajas/inconvenientes:

• Muy sencilla de implementar.
• Puede llevar al desperdicio de recursos, ya que la instancia de la clase se crea siempre, ya sea que se necesite o no.
• También se pierde tiempo de CPU en la creación de la instancia si no es necesaria.
• No es posible manejar excepciones.

2. Usando bloques static

Es muy similar al caso anterior. La única diferencia es que el objeto se crea en un bloque estático para que se pueda tener acceso a su creación, como el manejo de excepciones. De esta manera, el objeto también se crea en el momento de la carga de la clase.

Puede utilizarse cuando hay posibilidad de excepciones al crear el objeto con inicialización ansiosa.

// Código Java para crear una clase singleton
// Usando bloque estático
public class ClaseSingletonAD {
  // instancia pública
  public static ClaseSingletonAD instance;
 
  private ClaseSingletonAD() {
    // constructor privado
  }
  
  static {
    // bloque estático para inicializar la instancia
    instance = new ClaseSingletonAD();
  }
}

Ventanjas e inconvenientes:

• Muy sencillo de implementar.
• No es necesario implementar el método getInstance(). La instancia se puede acceder directamente.
• Las excepciones se pueden manejar en el bloque estático.
• Puede llevar al desperdicio de recursos, ya que la instancia de la clase se crea siempre, ya sea que se necesite o no.
• También se pierde tiempo de CPU en la creación de la instancia si no es necesaria.

3. Instanciación “perezosa” de Singleton

En este método, el objeto se crea sólo si es necesario. Esto puede evitar el desperdicio de recursos.

El objeto se crea en la implementación del método getInstance() que devuelva la instancia. Hay una comprobación de nulidad, y si el objeto no está creado, entonces se crea; de lo contrario, se devuelve el creado previamente.

Dado que el objeto se crea dentro de un método, se garantiza que el objeto no se creará a menos que sea necesario. La instancia se mantiene privada para que nadie pueda acceder directamente a ella.

Puede utilizarse en un entorno de un solo hilo porque varios hilos pueden romper la propiedad singleton al acceder al método getInstance() simultáneamente y crear varios objetos.

// inicialización perezosa (Lazy initialization)
public class ClaseSingletonAD {
  // instancia privada
  // sólo accesible desde el méttodo getInstance()
  private static ClaseSingletonAD instance;
 
  private ClaseSingletonAD() {
    // constructor privado
  }
 
  //devuelve la instancia de la clase
  public static ClaseSingletonAD getInstance() {
    if (instance == null) {
      // si la instancia es nula se inicializa
      instance = new ClaseSingletonAD();
    }
    return instance;
  }
}

Por ejemplo:

// Instanciación perezosa
public class RastreadorTicketsVisitantes {
    private static RastreadorTicketsVisitantes instancia;

    private RastreadorTicketsVisitantes() {
    }

    public static RastreadorTicketsVisitantes getInstance() {
        if (instancia == null) {
            instancia = new RastreadorTicketsVisitantes(); // ¡NO ES SEGURO PARA HILOS!
        }
        return instancia;
    }

    // Métodos de acceso a datos
    // ...
}

El RastreadorTicketsVisitantes, al igual que nuestras clases singleton, declara sólo constructores privados, crea una instancia de singleton y devuelve el singleton con un método getInstance(). Sin embargo, la clase RastreadorTicketsVisitantes crea el objeto singleton primera vez que un cliente lo solicita. Crear un objeto reutilizable la primera vez que se solicita es un patrón de diseño de software conocido como instanciación perezosa (Lazy Instantiation), que se usa a menudo junto con el patrón singleton.

Ventajas: La instanciación perezosa reduce el uso de memoria y mejora el rendimiento cuando se inicia una aplicación. De hecho, sin instanciación perezosa, la mayoría de los sistemas operativos y aplicaciones que ejecutas tardarían significativamente más en cargarse y consumirían mucha más memoria, quizás más memoria de la disponible en tu computadora.

Inconveniente:" El inconveniente de la instanciación perezosa es que los usuarios pueden notar un retraso notable la primera vez que se necesita un tipo particular de recurso, como una conexión a una base de datos.

Por ejemplo, muchas herramientas libres IDEs de desarrollo, como Eclipse, a menudo muestran un ligero retraso la primera vez que se abre un archivo Java en una ventana del editor después de iniciar el programa. Sin embargo, el retraso desaparece cuando se abren archivos Java adicionales. Este es un ejemplo de instanciación perezosa, ya que Eclipse sólo carga las bibliotecas para analizar y presentar archivos Java la primera vez que se abre un archivo Java.

• El objeto se crea sólo si es necesario. Puede superar el desperdicio de recursos y tiempo de CPU.
• El manejo de excepciones también es posible en el método.
• Se debe verificar la condición de nulo cada vez.
• La instancia no se puede acceder directamente.
• En un entorno multithread, puede romper la propiedad singleton.

Singleton en varias computadoras

En principio, los singletons son siempre únicos. Cuando se escriben aplicaciones que se ejecutan en varias computadoras, la solución estática de singleton comienza a requerir consideraciones especiales, ya que cada computadora tendría su propio JVM. En esas situaciones, aún se podría usar el patrón singleton, aunque podría implementarse con una base de datos o un servidor de colas en lugar de como un objeto estático.

4. Thread Safe Singleton

• Implementar verdaderamente el patrón singleton, debemos asegurarnos de que sólo se cree una instancia del singleton y está garantizado con el modelo anterior en entornos con un úncio hilo de ejecución.

• Marcar el constructor como privado evita que el singleton sea creado por otras clases, pero también se necesita asegurar que el objeto singleton sólo se crea una vez dentro de la propia clase singleton.

Se garantiza en los ejemplos de las clases AlmacenComida y RegistroPersonal utilizando el modificador final en la referencia estática.

Pero, en la instanciación perezosa en la clase RastreadorTicketsVisitantes, el compilador no permite asignar el modificador final a la referencia estática.

• La implementación de RastreadorTicketsVisitantes, como se muestra, no se considera segura para hilos de ejecución (Threads), ya que dos hilos podrían llamar a getInstance() al mismo tiempo, lo que daría lugar a la creación dos objetos. Después de que ambos hilos terminen de ejecutarse, sólo se establecerá y utilizará un objeto por otros hilos en adelante, pero el objeto que recibieron los dos hilos iniciales puede no ser el mismo.

La seguridad de hilos (Thread safety) es la propiedad de un objeto que **garantiza una ejecución segura por parte de múltiples hilos al mismo tiempo mediante el uso del modificador synchronized** (por ejemplo, es la diferencia entre StringBuilder y StringBuffer). Hace que el método getInstance() sea sincronizado para que múltiples hilos no puedan acceder a él simultáneamente.

public static synchronized RastreadorTicketsVisitantes getInstance() {
    if (instancia == null) {
        instancia = new RastreadorTicketsVisitantes();
    }
    return instancia;
}

El método getInstance() ahora está sincronizado, lo que significa que sólo se permitirá que un hilo entre en el método a la vez, asegurando que sólo se cree un objeto.

// Programa Java para crear una clase Singleton
// segura para subprocesos
public class ClaseSingletonAD 
{
  // instancia privada, para que sólo pueda ser
  // accedida por el método getInstance()
  private static ClaseSingletonAD instance;
 
  private ClaseSingletonAD() {
    // constructor privado
  }
 
  // método sincronizado para controlar el acceso simultáneo
  synchronized public static ClaseSingletonAD getInstance() {
    if (instance == null) {
      // si la instancia es nula, inicializar
      instance = new ClaseSingletonAD();
    }
    return instance;
  }
}

Ventajas e inconvenientes:

• La inicialización perezosa se implanta.
• También es seguro para threads.
• El método getInstance() está sincronizado, por lo que provoca un rendimiento lento, ya que varios hilos no pueden acceder a él simultáneamente.

5. Singletons con bloqueo de doble comprobación (Double‐Checked Locking)

La implementación sincronizada de getInstance(), aunque evita correctamente la creación de varios objetos singleton, tiene el problema de que cada llamada a este método requerirá sincronización. En la práctica, esto puede ser costoso y afectar el rendimiento.

La sincronización sólo es necesaria la primera vez que se crea el objeto. La solución es utilizar el doble bloqueo, un patrón de diseño en el que primero probamos si se necesita sincronización antes de adquirir cualquier bloqueo:

private static volatile ClaseSingleton instance;

public static ClaseSingleton getInstance() {
    if (instance == null) {
        synchronized (ClaseSingleton.class) {
            if (instance == null) {
                instance = new ClaseSingleton();
            }
        }
    }
    return instance;
}

Se añade el modificador volatile al objeto singleton. Esta palabra clave evita un caso sutil donde el compilador intenta optimizar el código de manera que el objeto se acceda antes de que termine de construirse.

Esta solución es mejor que la versión anterior, ya que realiza el paso de sincronización sólo cuando el singleton no existe. El singleton se accede miles de veces durante muchas horas o días, esto significa que sólo las primeras llamadas requerirían sincronización, y el resto no.

• Realiza inicialización perezosa.
• Es thread-safe
• Mejora el rendimiento, porque reduce la sincronización.
• La primera vez puede afectar al rendimiento.

Conclusión

Singleton es un patrón de diseño útil para permitir sólo una instancia de su clase, pero los errores comunes pueden permitir que se cree más de una instancia sin darse cuenta.

El propósito del Singleton es controlar la creación de objetos, limitando el número a uno pero permitiendo la flexibilidad de crear más objetos si la situación cambia. Dado que sólo hay una instancia de Singleton, cualquier campo de instancia de un Singleton aparecerá sólo una vez por clase, al igual que los campos estáticos.

Los singleton a menudo controlan el acceso a recursos como conexiones de bases de datos o sockets. Por ejemplo, si se tiene una licencia para una sola conexión para su base de datos o su controlador JDBC tiene problemas con subprocesos múltiples, Singleton se asegura de que sólo se realice una conexión o que sólo un subproceso pueda acceder a la conexión a la vez. Si añaden conexiones de base de datos o se utiliza un controlador JDBC que permite subprocesos múltiples, Singleton se puede ajustar fácilmente para permitir más conexiones.

Además, los Singleton pueden tener estado; en este caso, su función es servir como depósito único del Estado. Si está implementando un contador que necesita dar números secuenciales y únicos (como la máquina que da números en la tienda de delicatessen), el contador debe ser globalmente único. El Singleton puede retener el número y sincronizar el acceso; Si más adelante desea mantener contadores en una base de datos para lograr persistencia, puede cambiar la implementación privada de Singleton sin cambiar la interfaz.

Por otro lado, los Singleton también pueden proporcionar funciones de utilidad que no necesitan más información que sus parámetros. En ese caso, no hay necesidad de crear instancias de múltiples objetos que no tienen ninguna razón para su existencia, por lo que un Singleton es apropiado.

03. Objetos Inmutables

• Manejo de Objetos Mutables en los Constructores de Objetos Inmutables
• “Modificación” de un Objeto Inmutable

1. Creación de Objetos Inmutables

El próximo patrón creacional que discutiremos es el patrón de objetos inmutables, empelado para cuando deseamos tener objetos de sólo lectura para que sean compartidos y utilizados por varias clases.

A veces queremos crear objetos simples que puedan ser compartidos entre varias clases, pero por razones de seguridad no queremos que su valor sea modificado. Podríamos copiar el objeto antes de enviarlo a otro método, pero esto crea una gran sobrecarga que duplica el objeto cada vez que se pasa. Además, si tenemos varios hilos que acceden al mismo objeto, podríamos tener problemas de concurrencia, como veremos en el Capítulo 7.

Solución: El patrón de objeto inmutable es un patrón creacional basado en la idea de crear objetos cuyo estado no cambia después de que se crean y que se pueden compartir fácilmente entre varias clases. Los objetos inmutables van de la mano con la encapsulación, excepto que no existen métodos setter que modifiquen el objeto. Dado que el estado de un objeto inmutable nunca cambia, son inherentemente seguros para subprocesos.

Aplicación de una Estrategia Inmutable

Aunque hay una variedad de técnicas para escribir una clase inmutable, debes estar familiarizado con una estrategia común para hacer que una clase sea inmutable para el examen:

1. Usa un constructor para establecer todas las propiedades del objeto.
2. Marca todas las variables de instancia como privadas y finales.
3. No definas ningún método setter.
4. No permitas que los objetos mutables referenciados se modifiquen o accedan directamente.
5. Evita que los métodos se anulen.

La primera regla define cómo creamos el objeto inmutable, pasando la información al constructor para que todos los datos se establezcan al crearlo. Las segundas y terceras reglas son directas, ya que provienen de la encapsulación adecuada. Si las variables de instancia son privadas y finales, y no hay métodos setter, entonces no hay una forma directa de cambiar la propiedad de un objeto. Todas las referencias y valores primitivos contenidos en el objeto se establecen en la creación y no se pueden modificar.

La cuarta regla requiere una explicación más detallada. Supongamos que tienes un objeto inmutable Animal, que contiene una referencia a una lista de alimentos favoritos del animal, como se muestra en el siguiente ejemplo:

import java.util.*;

public final class Animal {
    private final List<String> favoriteFoods;

    public Animal(List<String> favoriteFoods) {
        if (favoriteFoods == null) {
            throw new RuntimeException("favoriteFoods is required");
        }
        this.favoriteFoods = new ArrayList<String>(favoriteFoods);
    }

    public List<String> getFavoriteFoods() { // ¡HACE LA CLASE MUTABLE!
        return favoriteFoods;
    }
}

Para asegurarnos de que la lista favoriteFoods no sea nula, la validamos en el constructor y lanzamos una excepción si no se proporciona. El problema en este ejemplo es que el usuario tiene acceso directo a la lista definida en nuestra instancia de Animal. Aunque no pueden cambiar el objeto List al que apunta, pueden modificar los elementos de la lista, por ejemplo, eliminando todos los elementos llamando a getFavoriteFoods().clear(). También podrían reemplazar, eliminar o incluso ordenar la lista.

La solución, entonces, es nunca devolver esa referencia de lista al usuario. De manera más general, nunca deb

es compartir referencias a un objeto mutable contenido dentro de un objeto inmutable. Si el usuario necesita acceso a los datos en la lista, ya sea creando métodos envolventes para iterar sobre los datos o creando una copia única de los datos que se devuelve al usuario y nunca se almacena como parte del objeto. De hecho, la API de Collections incluye el método Collections.unmodifiableList(), que hace exactamente esto.

La clave aquí es que ninguno de los métodos que creas debe modificar el objeto mutable.

Volviendo a nuestras cinco reglas, la última regla es importante porque evita que alguien cree una subclase de tu clase en la que un valor previamente inmutable ahora parece mutable. Por ejemplo, podrían anular un método que modifica una variable diferente en la subclase, ocultando essencialmente la variable privada definida en la clase principal. La solución más simple es marcar la clase o los métodos con el modificador final, aunque esto limita el uso de la clase. Otra opción es hacer que el constructor sea privado y aplicar el patrón de fábrica, que discutiremos más adelante en este capítulo.

Una clase Animal inmutable:

import java.util.*;

public final class Animal {
    private final String species;
    private final int age;
    private final List<String> favoriteFoods;

    public Animal(String species, int age, List<String> favoriteFoods) {
        this.species = species;
        this.age = age;
        if (favoriteFoods == null) {
            throw new RuntimeException("favoriteFoods is required");
        }
        this.favoriteFoods = new ArrayList<String>(favoriteFoods);
    }

    public String getSpecies() {
        return species;
    }

    public int getAge() {
        return age;
    }

    public int getFavoriteFoodsCount() {
        return favoriteFoods.size();
    }

    public String getFavoriteFood(int index) {
        return favoriteFoods.get(index);
    }
}

¿Sigue este ejemplo las cinco reglas? Bueno, todos los campos están marcados como privados y finales, y el constructor los establece al crear el objeto. Luego, no hay métodos setter y la clase en sí está marcada como final, por lo que los métodos no pueden ser anulados por una subclase. La clase contiene un objeto mutable, List, pero no hay referencias al objeto disponibles públicamente. Proporcionamos dos métodos para recuperar el número total de alimentos favoritos, así como un método para recuperar un alimento basado en un valor de índice. Ten en cuenta que String se considera inmutable, por lo que no tenemos que preocuparnos de que los objetos String se modifiquen. Por lo tanto, se cumplen las cinco reglas y las instancias de esta clase son inmutables.

Manejo de Objetos Mutables en los Constructores de Objetos Inmutables

Puedes notar que creamos un nuevo ArrayList en el constructor de Animal. Esto es absolutamente importante para evitar que la clase que crea inicialmente el objeto mantenga una referencia a la List mutable utilizada por Animal. Considera si hubiéramos hecho lo siguiente en el constructor:

this.favoriteFoods = favoriteFoods;

Con este cambio, el llamador que crea el objeto está utilizando la misma referencia que el objeto inmutable, lo que significa que ¡tiene la capacidad de cambiar la List! Es importante, al crear objetos inmutables, copiar cualquier argumento de entrada mutable a la instancia en lugar de usarlo directamente.

“Modificación” de un Objeto Inmutable

¿Cómo modificamos objetos inmutables si son inherentemente inmodificables? La respuesta es que ¡no podemos! Alternativamente, podemos crear nuevos objetos inmutables que contengan toda la misma información que el objeto original más lo que queríamos cambiar. Esto sucede cada vez que combinamos dos cadenas:

String firstName = "Grace";
String fullName = firstName + " Hopper";

En este ejemplo, firstName es inmutable y no se modifica al agregarse a fullName, que también es un objeto inmutable. También podemos hacer lo mismo con nuestra clase Animal. Imagina que queremos aumentar la edad de un Animal en uno. Lo siguiente crea dos instancias de Animal, la segunda utilizando una copia de los datos de la primera instancia:

// Crea una nueva instancia de Animal
Animal leon = new Animal("león", 5, Arrays.asList("carne", "más carne"));
// Crea una nueva instancia de Animal usando datos de la primera instancia
List<String> alimentosFavoritos = new ArrayList<String>();
for (int i = 0; i < leon.getFavoriteFoodsCount(); i++) {
    alimentosFavoritos.add(leon.getFavoriteFood(i));
}
Animal leonActualizado = new Animal(leon.getSpecies(), leon.getAge() + 1, alimentosFavoritos);

Dado que no teníamos acceso directo a la List mutable favoriteFoods, tuvimos que copiarla utilizando los métodos disponibles en la clase inmutable. También podríamos simplificar esto definiendo un método en Animal que devuelva una copia de la List de alimentos favoritos, siempre que el llamador comprenda que modificar esta List copiada no cambia el objeto Animal original de ninguna manera.

Programación estructurada básica

Abordaremos los contenidos más básicos de programación, que se corresponden con lo que se conoce como “programación estructurada” utilizando el lenguaje de programación Kotlin. No son contenidos muy detallados, sólo se alcanza el nivel de detalle suficiente para abordar los primeros retos algorítmicos.